Review Request: Add KMetaDataWidget and KMetaDataConfigurationDialog to kdelibs/kfile

[Aurélien Gâteau]

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


I would be interested in using this class in Gwenview because I like the way it renders information, but it would need to allow me to display my own properties. Can this be done or the class splitted in two (a generic property display widget, and a Nepomuk+KFileItem specialized display widget)?


trunk/KDE/kdelibs/kfile/kmetadatawidget.h
<http://reviewboard.kde.org/r/1938/#comment2184>

    It fills a bit backward to set hidden data. I believe it would be more natural to have a setVisibleData() method, or even setVisibleMetaDataTypes().


- Aurélien


On 2009-10-23 08:15:08, Peter Penz wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/1938/
> -----------------------------------------------------------
> 
> (Updated 2009-10-23 08:15:08)
> 
> 
> 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
> 
>