'Re: Review Request: Add KMetaDataWidget,'

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

List:       kde-core-devel
Subject:    Re: Review Request: Add KMetaDataWidget,
From:       "Peter Penz" <peter.penz () gmx ! at>
Date:       2010-03-22 22:24:39
Message-ID: 20100322222439.19745.66355 () localhost
[Download RAW message or body]



> On 2010-03-21 16:29:31, Aurélien Gâteau wrote:
> > I didn't look at individual lines closely as others have already did so. I think there was \
> > a misunderstanding regarding my suggestion on the initial request (as far as I remember \
> > what I suggested...). I think i suggested it would be more useful to have a widget to \
> > display a set of properties, but what I meant was that these properties do not have to be \
> > properties of a file. One could imagine for example a calendar showing the properties of a \
> > meeting. Since KMetaDataWidget is tied to files, I agree KMetaDataModel can be made \
> > private, at least for now. I must confess I also agree with Christopher about the name \
> > being a bit confusing. Even if, as Peter says "Qt has no ownership on the MVC pattern", I \
> > think Qt users have come to expect that classes suffixed with "Model" inherits from \
> > QAbstractItemModel or a subclass of it, in the same way that classes suffixed with "Widget" \
> > are expected to inherit from QWidget. 
> > One question though: I don't see the connection between KMetaDataWidget and \
> > KMetaDataConfigurationDialog. When does one create such a dialog? How does one link it to \
> > KMetaDataWidget?
> 
> Peter Penz wrote:
> As KMetaDataModel is a private API now, it won't be a problem to rename it. I'm open for any \
> suggestions, I somehow would like the name KMetaDataProvider as Christoph said... What do you \
> think? 
> Regarding KMetaDataWidget and KMetaDataConfigurationDialog: You can take Dolphin as example. \
> If you right click on the Information Panel and select "Configure...", you can configure \
> which of the meta data for the currently shown file type should be shown at all. IMO this \
> should not be possible only within Dolphin, but also in other applications that might use \
> this widget. 
> 
> 
> Aurélien Gâteau wrote:
> KMetaDataProvider sounds good.
> 
> About the dialog: what I was wondering was how was the developer supposed to "link" the \
> dialog and the widget. Looking at the code I realized they communicate via the "Nepomuk \
> KMetaDataConfigDialog" configuration group. Should the group be hardcoded? I don't really \
> know. Are there other places in kdelibs with hardcoded config groups like this? 
> Sebastian Trueg wrote:
> I think I have to agree with Aurelien as far as the widget is concerned. Why don't we call it \
> KFileMetaDataWidget to keep the possibility open to add a generic KMetaDataWidget later which \
> could then internally be used by the former. 
> About the dialog: I don't think a dialog is the best way to go. Other apps might want to \
> embed the config in some other place. So ideally at some point we would have a data model and \
> a filter model which has configuration methods to hide/show specific information bits. Since \
> the model is not public yet I also vote to hide the dialog/config for now. Then we figure out \
> how to configure the model. I know that this is taking the easy way out but as this is \
> already the second attempt at getting the class into kdelibs it could make sense to do it \
> step by step. 
> Peter Penz wrote:
> OK, I'll rename the widget to KFileMetaDataWidget. Regarding the dialog: The only thing I can \
> do is adding a @internal to the complete class, but it is not possible for me to move the \
> dialog from kdelibs to Dolphin, as the meta data model from kdelibs is private. Would this (= \
> adding an @internal to the class) be acceptable? 
> If possible it would be great having an answer until today 0:00, so that I don't have to wait \
> another week for the commit. Thanks! 
> Aurélien Gâteau wrote:
> About the dialog: maybe you can turn it into a widget? This way applications can embed it in \
> a configuration dialog.

Good idea :-) I just committed the patch and turned the configuration dialog into a widget -> \
the interface is now very minimal and might be a good base to get a public API later.


- Peter


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


On 2010-03-22 18:02:40, Peter Penz wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/3277/
> -----------------------------------------------------------
> 
> (Updated 2010-03-22 18:02:40)
> 
> 
> Review request for kdelibs, Sebastian Trueg, David Faure, and Aurélien Gâteau.
> 
> 
> Summary
> -------
> 
> The patch adds KMetaDataWidget, KMetaDataModel and KMetaDataConfigurationDialog as public \
> classes to kdelibs/kfile. The 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 (see http://enzosworld.gmxhome.de/temp/metadatawidget.png or attached \
> screenshot). 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, ...). It is possible for applications to add custom meta data if wanted \
> (including widgets to manipulate this meta data). 
> 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. I'd also like to to adjust KPropertiesDialog later to use this widget. 
> I'd ask mainly to look at the files kfile/kmetadatawidget.h, kfile/kmetadatamodel.h and \
> kfile/kmetadataconfigurationdialog.h, the other APIs are internal. 
> Thanks!
> 
> 
> Diffs
> -----
> 
> trunk/KDE/kdelibs/CMakeLists.txt 1106199 
> trunk/KDE/kdelibs/config-nepomuk.h.cmake PRE-CREATION 
> trunk/KDE/kdelibs/kfile/CMakeLists.txt 1106199 
> 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/kfilemetadataconfigurationdialog.h PRE-CREATION 
> trunk/KDE/kdelibs/kfile/kfilemetadataconfigurationdialog.cpp PRE-CREATION 
> trunk/KDE/kdelibs/kfile/kfilemetadataprovider.cpp PRE-CREATION 
> trunk/KDE/kdelibs/kfile/kfilemetadataprovider_p.h PRE-CREATION 
> trunk/KDE/kdelibs/kfile/kfilemetadatawidget.h PRE-CREATION 
> trunk/KDE/kdelibs/kfile/kfilemetadatawidget.cpp PRE-CREATION 
> trunk/KDE/kdelibs/kfile/kloadfilemetadatathread.cpp PRE-CREATION 
> trunk/KDE/kdelibs/kfile/kloadfilemetadatathread_p.h PRE-CREATION 
> trunk/KDE/kdelibs/kfile/knfotranslator.cpp PRE-CREATION 
> trunk/KDE/kdelibs/kfile/knfotranslator_p.h 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 1106199 
> trunk/KDE/kdelibs/nepomuk/core/ui/nepomukmassupdatejob.h 1106199 
> trunk/KDE/kdelibs/nepomuk/core/ui/nepomukmassupdatejob.cpp 1106199 
> 
> Diff: http://reviewboard.kde.org/r/3277/diff
> 
> 
> Testing
> -------
> 
> Tested in Dolphin. An early version has been tested also in Mailody and Okular.
> 
> 
> Screenshots
> -----------
> 
> KMetaDataWidget
> http://reviewboard.kde.org/r/3277/s/330/
> 
> 
> Thanks,
> 
> Peter
> 
> 


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