Review Request 111897: Move KFileMetaData (and friends) to kde4support

[Vishesh Handa]

> On Aug. 6, 2013, 9 a.m., Vishesh Handa wrote:
> > I was just working on the same thing.
> > 
> > I'm not sure if we want to move this to kde4support. Can we just throw it away? Or would that be terribly wrong? We have a replacement in nepomuk-widgets.
> > 
> > Strigi doesn't need to be ported to Qt5 since it is does not use Qt. Soprano will have to be, but I don't think this code uses Soprano.
> 
> Aleix Pol Gonzalez wrote:
>     You were working on it? -.- it didn't have your name on it...
>     
>     I think that the classes called plugin should be removed, there's not much else to remove otherwise.

I'd just started today morning, then I decided to try and compile everything. It has been 5 hours since then. I'm still compiling.

There is just one user visible class - KFileMetadataWidget. The rest of the classes are helper code. A large part of the helper code uses Nepomuk1. If we move this to kde4support, then those Nepomuk1 dependencies have to be removed. Removing them would make this into a wrapper over Strigi. The question is - do we want that? Or do we just want to discard this class completely?

Based on [1] there seem to be 3 clients. Dolphin which uses it when Nepomuk compilation is disabled. Conquirere, which is a Nepomuk based app and should just use the one in nepomuk-widgets, and Konversation - I'm not sure what to do about them. If we throw away this class then we will just be breaking Konversation.

I'm obviously in favor of discarding the class. Opinions?

This also raises the larger question if we want classes in kde4support to depend on unmaintained code? (Strigi)

[1] http://lxr.kde.org/ident?i=KFileMetaDataWidget


- Vishesh


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


On Aug. 5, 2013, 6:06 p.m., Aleix Pol Gonzalez wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/111897/
> -----------------------------------------------------------
> 
> (Updated Aug. 5, 2013, 6:06 p.m.)
> 
> 
> Review request for KDE Frameworks and Vishesh Handa.
> 
> 
> Description
> -------
> 
> As far as I've understood, we should have an alternative by Nepomuk for file previewing for KF5, this patch moves the KFileMetaInfo and the files that depend on it to KDE4Support.
> 
> It's worth noting that there are 2 "plugins" (they're actually not plugins) of the KPropertiesDialog that have been disabled because they had to be moved with KFileMetaInfo. That is the kmetaprops.cpp and kpreviewprops.cpp
> 
> 
> Diffs
> -----
> 
>   kio/CMakeLists.txt 035cf70 
>   kio/kfile/kfilemetadataconfigurationwidget.h 6be2a0d 
>   kio/kfile/kfilemetadataconfigurationwidget.cpp  
>   kio/kfile/kfilemetadataprovider.cpp  
>   kio/kfile/kfilemetadataprovider_p.h 8009bf4 
>   kio/kfile/kfilemetadatareader.cpp  
>   kio/kfile/kfilemetadatareader_p.h  
>   kio/kfile/kfilemetadatareaderprocess.cpp  
>   kio/kfile/kfilemetadatawidget.h 2dc4677 
>   kio/kfile/kfilemetadatawidget.cpp  
>   kio/kfile/kmetaprops.h a08c380 
>   kio/kfile/kmetaprops.cpp  
>   kio/kfile/knfotranslator.cpp  
>   kio/kfile/knfotranslator_p.h  
>   kio/kfile/kpreviewprops.h 8a974da 
>   kio/kfile/kpreviewprops.cpp  
>   kio/kfile/kpropertiesdialog.cpp 687e4bf 
>   staging/kde4support/src/CMakeLists.txt 1d6369f 
>   staging/kde4support/src/config-kde4support.h.cmake 03d3bf4 
> 
> Diff: http://git.reviewboard.kde.org/r/111897/diff/
> 
> 
> Testing
> -------
> 
> builds... actually i'm not sure if there's Qt5 soprano/strigi. what's hte status?
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20130806/247ce1ef/attachment-0001.html>