'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