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