Review Request: Add KMetaDataWidget, KMetaDataModel and KMetaDataConfigurationDialog

David Faure faure at kde.org
Sat Mar 20 00:05:22 GMT 2010 

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



trunk/KDE/kdelibs/kfile/kcommentwidget.cpp
<http://reviewboard.kde.org/r/3277/#comment4050>

    Qt::Dialog can be removed; QDialog takes care of setting that flag internally.



trunk/KDE/kdelibs/kfile/kcommentwidget.cpp
<http://reviewboard.kde.org/r/3277/#comment4051>

    The KConfigBase::Persistent can be removed; the default value is Normal which is equal to Persistent. The explicit value just made the code more confusing to my eyes ("is this trying to remove another default flag, or something?").



trunk/KDE/kdelibs/kfile/kedittagsdialog.cpp
<http://reviewboard.kde.org/r/3277/#comment4052>

    The parent widget should be mainWidget, not this. Current code works, but reparents.



trunk/KDE/kdelibs/kfile/kedittagsdialog.cpp
<http://reviewboard.kde.org/r/3277/#comment4053>

    In one line with m_deleteButton->setGeometry(x, y, size, size);



trunk/KDE/kdelibs/kfile/kloadmetadatathread.cpp
<http://reviewboard.kde.org/r/3277/#comment4059>

    Race condition here; the thread could be not finished at the time of the isFinished() call, but could be finished before you connect to its finished() signal, so you'd miss the signal.
    
    The only way to do this properly is with a QSemaphore I suppose; hmm, not sure how exactly. Would be better to not need that if basically, and to always connect finished() to a slot in the main thread - which you seem to do anyway, right? So from the main thread you can decide reliably whether you've seen the finished signal already or not. But doing the connect here (at a random point in the lifetime of the thread) is wrong.
    
    In fact, this method is unused, isn't it? I would just remove it then.



trunk/KDE/kdelibs/kfile/kloadmetadatathread.cpp
<http://reviewboard.kde.org/r/3277/#comment4058>

    I am very surprised to see no locking at all in this thread.
    This will crash if m_model is deleted while the thread is running, which doesn't seem to be handled at all. The model has to cancel() all threads, then wait() on them, before it can proceed with letting itself be deleted.
    
    But note that in wait() it won't process events, so the slotFinished of the model won't be called. So the cleanups (and deletion of the thread instance) have to be done in that method, rather than assuming the slotFinished cleanups will happen.
    
    More generally, since this implements a thread, I strongly suggest running this code in valgrind --tool=helgrind, preferrably from a unittest.



trunk/KDE/kdelibs/kfile/kloadmetadatathread_p.h
<http://reviewboard.kde.org/r/3277/#comment4054>

    Should be marked as volatile if it's modified by a thread and read by another (without locking). I'm told it matters on some architectures (not x86).



trunk/KDE/kdelibs/kfile/kmetadataconfigurationdialog.cpp
<http://reviewboard.kde.org/r/3277/#comment4060>

    Remove 2nd argument



trunk/KDE/kdelibs/kfile/kmetadatamodel.h
<http://reviewboard.kde.org/r/3277/#comment4061>

    As you suspected, including config-nepomuk.h and using HAVE_NEPOMUK in a public header is a big no-no. It makes the header unusable in other modules, unless they replicate the creation of a config-nepomuk.h, we usually don't do this.
    
    We heard the rule "no #ifdef HAVE_FOO in public header files" many many times in kde3 times, I would say it still applies.
    
    But I'm not sure what to suggest instead. Well, maybe to just use nepomuk unconditionally in all the files and to compile them and use them only if nepomuk support is enabled. At least this doesn't impose on users of the file that they should have a config-nepomuk.h.



trunk/KDE/kdelibs/kfile/kmetadatamodel.cpp
<http://reviewboard.kde.org/r/3277/#comment4055>

    How about passing the thread pointer as parameter, to avoid having to use sender()?



trunk/KDE/kdelibs/kfile/kmetadatamodel.cpp
<http://reviewboard.kde.org/r/3277/#comment4056>

    The thread's slotFinished does deleteLater already, doesn't it?



trunk/KDE/kdelibs/kfile/kmetadatamodel.cpp
<http://reviewboard.kde.org/r/3277/#comment4057>

    Same here; done by the thread already.  [That is, by the thread class; the slotFinished and the deleteLater will happen in the main thread, obviously]



trunk/KDE/kdelibs/kfile/kmetadatamodel.cpp
<http://reviewboard.kde.org/r/3277/#comment4062>

    So, this is going to be called from another thread, and currently without any locking at all. That makes me quite suspicious, but then again, there's no actual implementation of loadData() in this patch, right? I'm just curious to see how one would implement this properly.



trunk/KDE/kdelibs/kfile/kmetadatawidget.cpp
<http://reviewboard.kde.org/r/3277/#comment4064>

    What if the URL is remote? In case setItems(KUrl) was called, the KFileItem will contain absolutely no time/user/permission information. I suppose this needs to test for invalid time etc. in order to show something more user-friendly.
    Even isDir() isn't going to work, if a real kfileitem wasn't provided as input. I guess the API docs should warn about this, too.



trunk/KDE/kdelibs/kfile/ktaggingwidget.cpp
<http://reviewboard.kde.org/r/3277/#comment4063>

    Remove Qt::Dialog


- David


On 2010-03-16 20:39:25, Peter Penz wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/3277/
> -----------------------------------------------------------
> 
> (Updated 2010-03-16 20:39:25)
> 
> 
> 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 1103259 
>   trunk/KDE/kdelibs/config-nepomuk.h.cmake PRE-CREATION 
>   trunk/KDE/kdelibs/kfile/CMakeLists.txt 1103259 
>   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/kloadmetadatathread.cpp PRE-CREATION 
>   trunk/KDE/kdelibs/kfile/kloadmetadatathread_p.h PRE-CREATION 
>   trunk/KDE/kdelibs/kfile/kmetadataconfigurationdialog.h PRE-CREATION 
>   trunk/KDE/kdelibs/kfile/kmetadataconfigurationdialog.cpp PRE-CREATION 
>   trunk/KDE/kdelibs/kfile/kmetadatamodel.h PRE-CREATION 
>   trunk/KDE/kdelibs/kfile/kmetadatamodel.cpp PRE-CREATION 
>   trunk/KDE/kdelibs/kfile/kmetadatawidget.h PRE-CREATION 
>   trunk/KDE/kdelibs/kfile/kmetadatawidget.cpp 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 1103259 
>   trunk/KDE/kdelibs/nepomuk/core/ui/nepomukmassupdatejob.h 1103259 
>   trunk/KDE/kdelibs/nepomuk/core/ui/nepomukmassupdatejob.cpp 1103259 
> 
> 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
> 
>

More information about the kde-core-devel mailing list