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

[Frank Reininghaus]

> 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.
> 
> Vishesh Handa wrote:
>     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

> Dolphin which uses it when Nepomuk compilation is disabled.

Yes. However, I think we might want to drop the option to compile Dolphin without Nepomuk 2 when porting to Frameworks. Maintaining all the HAVE_NEPOMUK #ifdefs is not much fun, in particular not if the only benefit for the users who compile from source is that they can make Dolphin use unmaintained code.

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

I think that this is a good idea. Maybe one could make it a typedef for (or a very thin wrapper around) Nepomuk2::MetaDataWidget? Then removing all this unmaintained code would even be a source compatible change. Maybe this is not possible right now because kdelibs cannot depend on nepomuk-widgets, but in the long term, it makes sense IMHO to have kde4support depend on all KDE libs that are required to make the porting as easy as possible.


- Frank


-----------------------------------------------------------
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/89ccbb50/attachment.html>