Review Request 119895: New class for 5.2 to help user to migrate config files and ui file to new standardpath

[Kevin Krammer]

On Aug. 22, 2014, 9:39 vorm., Laurent Montel wrote:
> > Just a general question: do we really want a porting class in core addons?
> 
> Laurent Montel wrote:
>     Kdelibs4Migration is already in this addons.
>     Where do you want to put it ? In which module ?
> 
> Kevin Krammer wrote:
>     I just found it strange.
>     To me it is like having Qt3Support in QtCore. But I don't know what the goal of KDE core addons is, so providing compatibility stuff might very well be part of its scope.
> 
> David Faure wrote:
>     Well, it's not the same. You want to be able to port away from Qt3support / kdelibs4support at some point, to stop linking to it.
>     
>     On the other hand, you need to keep calling kdelibs4migrator for the entire 5.x lifetime, since you can't know at which point the last users will switch. So you don't want such code in a compatibility library that you're trying to stop linking to.
> 
> Kevin Krammer wrote:
>     Well, that is only the case for applications which used to use kdelibs in their Qt4 version.
>     It is just a single class for now, but if we also want to support data migration at some point this is going to need asynchronous copying, etc. adding to the complexity of a library targetted at more than just ported KDE applications, no?
> 
> Laurent Montel wrote:
>     For data, not all applications needs it. So I don't know if I will add in this class.
>     But indeed if we need to put it in this class we need to make it async.
>     But what is the problem with it ?
>     
>     As David wrote we need to have it in all kf5 life so we need to put it in a specific module and we can't put it in kdelibs4support module.
> 
> Kevin Krammer wrote:
>     I have to say I am not really sure what the goal here is.
>     The base need is a way for applicaiton developers to find their old files, basically a KStandardDirs implementation.
>     If we really want to provide tools on top of that, wouldn't a dedicated framework be a better choice?
>     How likely does an application only have config and ui.rc and no data?
> 
> David Faure wrote:
>     I think Laurent is thinking of kdepim, where the data (akonadi DB etc.) was already in XDG dirs anyway, so it doesn't need to be migrated.
>     
>     Many other apps don't have local data at all (okular, gwenview, kolourpaint, etc. etc.). At most a config file and ui.rc files, which is now covered.
>     
>     Apps with specific data would have to handle that specifically anyway.
>     
>     So we're left with two classes (one returning paths and one migrating the common case of foorc and fooui.rc), which "pollute" kcoreaddons to avoid creating a whole framework just for two classes. I can't exactly see how this would be a problem for other kcoreaddons users though.
>     They're not using all of the QtCore classes either, for sure :-)

As I said before, it just felt weird to me.
As for data, I have more than 100 subdirs in .kde/share/apps, including okular and gwenview. could be empty, but apparently something created them


- Kevin


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119895/#review65016
-----------------------------------------------------------


On Aug. 22, 2014, 10:55 vorm., Laurent Montel wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119895/
> -----------------------------------------------------------
> 
> (Updated Aug. 22, 2014, 10:55 vorm.)
> 
> 
> Review request for KDE Frameworks, David Faure and Kevin Krammer.
> 
> 
> Repository: kcoreaddons
> 
> 
> Description
> -------
> 
> Class helps user to migrate config file and ui file to new location
> 
> 
> Diffs
> -----
> 
>   autotests/CMakeLists.txt 75d1293 
>   autotests/data/appui1rc PRE-CREATION 
>   autotests/data/appuirc PRE-CREATION 
>   autotests/data/foo1rc PRE-CREATION 
>   autotests/data/foorc PRE-CREATION 
>   autotests/kdelibs4configmigratortest.cpp PRE-CREATION 
>   src/lib/CMakeLists.txt 26eb5a1 
>   src/lib/util/kdelibs4configmigrator.h PRE-CREATION 
>   src/lib/util/kdelibs4configmigrator.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/119895/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Laurent Montel
> 
>

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