Changes in libkipi
Locked
 
|
Hello everyone!
I've added a function in libkipi that returns the tagModel from digikam. I've needed a new function instead of the existing selection widget because selection widget had some extra options that are not needed in gpssync(like the search tool or album selection tool).
The code from libkipi is here [0] (interface.h, interface.cpp) and the changes from digikam's kipiinterface are here [1] (kipiinterface.h, kipiinterface.cpp). If you have any observation or suggestion about this, please tell me.
Gabriel Voicu _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
Change are fine for me.
Your new kipiinterface.cpp/.h changes must be integrated in digiKam GoSC branche : http://websvn.kde.org/branches/extragear/graphics/digikam/gsoc-2010/ This digiKam version is delegate to host all change done during GoSC 2010. It include face detection and image versioning. This branch is synchronized with trunk by Marcel Libkipi code cannot be included to trunk now. You must wait KDE 4.5 release (planed this summer), to not break binary compatibility. library API and ABI version ID must be increased. Gilles Caulier 2010/6/18 Gabriel Voicu <[hidden email]>: > Hello everyone! > I've added a function in libkipi that returns the tagModel from digikam. > I've needed a new function instead of the existing selection widget because > selection widget had some extra options that are not needed in gpssync(like > the search tool or album selection tool). > The code from libkipi is here [0] (interface.h, interface.cpp) and the > changes from digikam's kipiinterface are here [1] (kipiinterface.h, > kipiinterface.cpp). > If you have any observation or suggestion about this, please tell me. > Gabriel Voicu > [0] websvn.kde.org/branches/extragear/graphics/libkipi-gsoc-2010/libkipi/ > [1] websvn.kde.org/branches/extragear/graphics/gsoc-geocoding/ > _______________________________________________ > Digikam-devel mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-devel > > Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
In reply to this post by Gabriel Voicu
> Hello everyone! > > I've added a function in libkipi that returns the tagModel from digikam. > I've needed a new function instead of the existing selection widget because > selection widget had some extra options that are not needed in gpssync(like > the search tool or album selection tool). > > The code from libkipi is here [0] (interface.h, interface.cpp) and the > changes from digikam's kipiinterface are here [1] (kipiinterface.h, > kipiinterface.cpp). > > If you have any observation or suggestion about this, please tell me. - a model or a widget? Getting a widget (for digikam, a TagTreeView) will ensure consistent behavior with widgets in the application. Btw, if only a model is returned, you dont need a widget as parent. - how do you want to retrieve the selected tag? Qt::DisplayRole is not enough. You could define a role returning a unique identifier (for digikam, the tag path). Different suggestion: Create two new classes in libkipi: - One class representing a tag, inheriting KipiImageCollection, but with additional methods: - a tag name and an identifier (= tag path) - constructable and creatable from a tag path - you can get and set attributes to tags (an optional Kipi::Interface feature), as you need it. Name-value pairs, similar to KipiImageInfo's attributes. - assigning tags can still be done via KipiImageInfo::addAttributes - one tag selection widget (for digikam, trivially inheriting TagTreeView) - returning the currently selected Kipi Tag object + any more needs you have for your project > > Gabriel Voicu > > [0] websvn.kde.org/branches/extragear/graphics/libkipi-gsoc-2010/libkipi/ > [1] websvn.kde.org/branches/extragear/graphics/gsoc-geocoding/ _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
2010/6/20 Marcel Wiesweg <[hidden email]>:
> >> Hello everyone! >> >> I've added a function in libkipi that returns the tagModel from digikam. >> I've needed a new function instead of the existing selection widget because >> selection widget had some extra options that are not needed in gpssync(like >> the search tool or album selection tool). >> >> The code from libkipi is here [0] (interface.h, interface.cpp) and the >> changes from digikam's kipiinterface are here [1] (kipiinterface.h, >> kipiinterface.cpp). >> >> If you have any observation or suggestion about this, please tell me. > > - a model or a widget? Getting a widget (for digikam, a TagTreeView) will > ensure consistent behavior with widgets in the application. I'm agree with marcel, creating a template widget in libkipi to display a tagtreeview will be better. The widget creation must be done in kipi host application. To delegate this on digiKam, this will give an homogenous view of tree view, and can be shared with another plugins as well. Don't forget that plugins are shared with others hosts as gwenview or kphotoalbum which have a different view for keywords management. As, i have already said previously, this is already done like this for collection selection widget used in HTMLExport or FlashExport for ex. Code is there : http://websvn.kde.org/*checkout*/trunk/KDE/kdegraphics/libs/libkipi/libkipi/uploadwidget.h?revision=911273 http://lxr.kde.org/source/extragear/graphics/kipi-plugins/flashexport/selectionpage.cpp#58 http://lxr.kde.org/source/extragear/graphics/digikam/utilities/kipiiface/kipiuploadwidget.h Gilles Gilles _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
Thank you, Gilles and Marcel, for answering.
The idea is that I need the tag model, not just for selecting a single tag, but to also manipulate the whole tag tree. I know that at beginning I said the tag will be just for selection, but after speaking with Michael Hansen we've decided to do something better. For this, I'm working on a submodel that gets data from tag model and manipulates it inside gpssync. I've uploaded an example on how it will work: 1) Let's say this is the tag tree from digikam showed in reversegeocoding widget from gpssync. The tag tree is displayed in a tag tree view. http://img85.imageshack.us/img85/2636/tagtreewidget1.jpg 2) The user right-clicks "Places" tag, selects "Create Country tag" and a tag "{Country}" is created as a child of "Places". Then he right-clicks the "{Country}" tag and selects "Create City tag" as a child of "{Country}". http://img267.imageshack.us/img267/1015/tagtreewidget2.jpg 3) The {Country} and {City} tags are listed in the tag tree. If the user wants, he can delete them (I will leave the deletion part at the end). http://img243.imageshack.us/img243/828/tagtreewidget3.jpg 4) Let's say the user has selected some photos made in Romania, Bucharest. After clicking the button "Apply reverse geocoding", the {Country} and {City} tags will be replaced with "Romania" and "Bucharest". http://img337.imageshack.us/img337/8416/tagtreewidget4.jpg The user will have the possibility to add as many {Country} and {City} tags as he wants. I've made this example only with {Country} and {City}, but there will also be {State}, {Country}, {Street}, {Street number}. About tags attributes that Marcel mentioned in his e-mail, I will follow his advice. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
«
Return to digikam-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |