Review Request: Add KMetaDataWidget and KMetaDataConfigurationDialog to kdelibs/kfile

Tue Oct 27 20:56:41 GMT 2009

> On 2009-10-27 08:52:11, Aurélien Gâteau wrote:
> > My idea about splitting was not making a Nepomuk version and a non Nepomuk version but rather having a generic widget (say KPropertyWidget) capable of displaying a set of properties. These properties may not be linked to files. You could then either implement KMetaDataWidget on top of it, or provide an additional class to fill KPropertyWidget with KFileItem and Nepomuk information.
> > 
> > The more I think of it, the more I believe this could be done using Qt model/view system: KPropertyWidget could be a view capable of showing any model which provide key/value data. The model would provide two columns, one for key and the other for value. One could then provide a QItemDelegate implementation to provide rendering and editor for specific keys (for example rating). Bonus points for making it possible to group keys using a hierarchical model.
> > 
> > Of course this is a lot of work :/ but I believe it would make the widget more useful.
> 
> Josef Spillner wrote:
>     I would like to give +1 for this idea. When we think about the buzz of the social semantic service-oriented desktop, such a generic metadata widget looks like a good idea. It allows users to organise their information and collaboration items, and files are a subset of this.
>     A particular use case I have in mind for one of my applications is showing the (read-only) properties of products and services in an app store-like application, which are derived from user ratings and other information sources. Currently, the client is written in Java, and having powerful widgets available would increase the incentive to port it to a native desktop application.
> 
> Peter Penz wrote:
>     I like your suggestion a lot. As mentioned above: After discussing all the different meta data types (dynamic vs. fixed vs. custom meta data) it would be a risk IMO to try to get KMetaDataWidget into kdelibs in this shape. As you say it is a lot of work to change the code to use your approach, but in the longterm I think it is the better choice. I cannot come up with a solution for KDE 4.4 (too less time), but I try to get the widget in shape in Dolphin for the KDE 4.5 cycle and will try again in a few months ;-)
>     
>     Thanks to all for your input. If the outcome of a review is that the widget is not in shape for kdelibs, then this is a good motivation trying to come up with a better solution :-)

Sounds like a good plan. I would be very happy to integrate pre-versions of these classes in Gwenview to give them more testing, so do not hesitate to CC me.

- Aurélien

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/1938/#review2823
-----------------------------------------------------------

On 2009-10-27 08:06:19, Peter Penz wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1938/
> -----------------------------------------------------------
> 
> (Updated 2009-10-27 08:06:19)
> 
> 
> Review request for kdelibs, Sebastian Trueg and David Faure.
> 
> 
> Summary
> -------
> 
> The patch adds KMetaDataWidget and KMetaDataConfigurationDialog as public classes to kdelibs/kfile. KMetaDataWidget allows an application in an easy way to show meta data of a file (or several files). The widget also allows to change meta data like tags, comments and rating: http://enzosworld.gmxhome.de/temp/metadatawidget_new.png KMetaDataConfigurationDialog allows to configure which meta tags should be hidden/shown. The classes also work without Nepomuk (and show only very basic meta data like size, permissions, ...).
> 
> The classes have been used by Dolphin internally until now and have originally been written by Sebastian Trüg. After the request from Tom Albers and Oliver Heidbüchel to integrate the widget also in Mailody/Okular I've adjusted the classes to get them ready for a kdelibs-integration.
> 
> Sebastian Trüg, Tom Albers, Oliver Heidbüchel and I did already an internal review and the classes have been tested in the context of Mailody and Okular. There are still some minor implementation issues, but the main reason for this request is to review the public API and the integration into kdelibs/kfile (I'll take care to fix the issues until KDE 4.4).
> 
> I'd ask to mainly look at the files kfile/kmetadatawidget.h, kfile/kmetadataconfigurationdialog.h and kfile/CMakeLists.txt One ugly hack in the header file is the HAVE_NEPOMUK part in kmetadatawidget.h. As Nepomuk runs with Virtuoso now, the chances are good that we can get rid of this hack until KDE 4.4 (see also http://lists.kde.org/?l=kde-core-devel&m=125577498913008&w=2 for the discussion on kde-core-devel).
> 
> Please let me know whether there are general concerns regarding the location or the HAVE_NEPOMUK issue.
> 
> 
> Diffs
> -----
> 
>   trunk/KDE/kdelibs/kfile/CMakeLists.txt 1038666 
>   trunk/KDE/kdelibs/kfile/kcommentwidget.cpp PRE-CREATION 
>   trunk/KDE/kdelibs/kfile/kcommentwidget_p.h PRE-CREATION 
>   trunk/KDE/kdelibs/kfile/kedittagsdialog.cpp PRE-CREATION 
>   trunk/KDE/kdelibs/kfile/kedittagsdialog_p.h PRE-CREATION 
>   trunk/KDE/kdelibs/kfile/kmetadataconfigurationdialog.h PRE-CREATION 
>   trunk/KDE/kdelibs/kfile/kmetadataconfigurationdialog.cpp PRE-CREATION 
>   trunk/KDE/kdelibs/kfile/kmetadatawidget.h PRE-CREATION 
>   trunk/KDE/kdelibs/kfile/kmetadatawidget.cpp PRE-CREATION 
>   trunk/KDE/kdelibs/kfile/ktaggingwidget.cpp PRE-CREATION 
>   trunk/KDE/kdelibs/kfile/ktaggingwidget_p.h PRE-CREATION 
>   trunk/KDE/kdelibs/nepomuk/core/ui/CMakeLists.txt 1038666 
>   trunk/KDE/kdelibs/nepomuk/core/ui/nepomukmassupdatejob.h 1038666 
>   trunk/KDE/kdelibs/nepomuk/core/ui/nepomukmassupdatejob.cpp 1038666 
> 
> Diff: http://reviewboard.kde.org/r/1938/diff
> 
> 
> Testing
> -------
> 
> Tested in Dolphin, Mailody and Okular. Some minor implementation issues are open, but the interface seems to be sufficient.
> 
> 
> Thanks,
> 
> Peter
> 
>