'Re: Review Request: Add KMetaDataWidget and'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Review Request: Add KMetaDataWidget and
From:       "Peter Penz" <peter.penz () gmx ! at>
Date:       2009-10-27 11:26:19
Message-ID: 20091027112619.23772.42797 () localhost
[Download RAW message or body]



> 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.

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 :-)


- Peter


-----------------------------------------------------------
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
> 
> 


[prev in list] [next in list] [prev in thread] [next in thread]
Configure | About | News | Add a list | Sponsored by KoreLogic