> On April 12, 2014, 11:12 a.m., Kevin Krammer wrote: > > I wonder if this really belongs in kdecoreaddons. I.e. it is only relevant > > for KDE applications porting, right? > > IMHO this would fit best in an explicit porting framework > > David Faure wrote: > I don't want to put this in kdelibs4support because apps are supposed to > port away from that and stop linking to it (thus avoiding "I link to > everything"), > while they are supposed to keep the migration code for quite some time > (not everyone will upgrade to 5.0 right away). > > I don't think it makes sense to create yet another framework for one > class. We are going crazy already with the number of frameworks and the small > size of some of them. > > So this leaves.... kcoreaddons, unless you have a better suggestion. > > > Kevin Ottens wrote: > If that's really only about configuration, why not kconfig? That's where > we have the config update tooling too. I'd find it less surprising there. If > not strictly about configuration kcoreaddons seems the only sane option > indeed. > > Kevin Krammer wrote: > It is not just for config, there is already a function for returning "KDE > data home". > However that brings up a new question from me: what about the other > resource types? > > If I were to port away from KStandardDirs I would like to be able to find > old locations of my files and my access right now might not be to just config > and data. > All my initial assumptions on porting were based on KStandardDirs still > existing and finding the paths as usual. > My understanding is taht this is no longer true, i.e. because > KStandardDirs behaves differently in the porting framework version. > So this "legacy dir support class" needs to be basically be > KStandardDirs's user local implementation, e.g. allowing locate(), etc.
Which other resource types would be useful, exactly? In my ~/.kde4/share, apart from "config" and "apps", I can only see (after cleaning up some useless cruft like applnk and mimelnk) "wallpapers" and "kde4/services" (due to a locally-defined searchprovider). Most "services" would be kde4 plugins that wouldn't make sense in kf5 though. I can move my custom searchproviders definitions by hand ;) Anything else you guys have? locate() is not very useful in the context of migrations: it searches at all levels, while we only want to care for files in the user's home. This is why most of the KStandardDirs logic doesn't really apply anymore. locateLocal() is basically what we're doing with QFile::exists(configHome()+"kfoorc"). "wallpapers" is however a good example of a resource type that is missing. So maybe we can make this based on resource strings again like kstandarddirs used to be, to support the resources that make sense without adding too much api... ? - David ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117511/#review55504 ----------------------------------------------------------- On April 12, 2014, 11:01 a.m., David Faure wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/117511/ > ----------------------------------------------------------- > > (Updated April 12, 2014, 11:01 a.m.) > > > Review request for KDE Frameworks, Ivan Čukić and Kevin Krammer. > > > Repository: kcoreaddons > > > Description > ------- > > Add class for finding the kde4 config and apps home dirs. > > To help applications migrating to the kf5/qt5 directories. > > > Diffs > ----- > > autotests/CMakeLists.txt 7ab7bc43be1434ae93f7c77af90e41bbde5168ac > autotests/kdelibs4migrationtest.cpp PRE-CREATION > src/lib/CMakeLists.txt 1d17874f0da428bd34ea85ee98683f6fef620c81 > src/lib/util/kdelibs4migration.h PRE-CREATION > src/lib/util/kdelibs4migration.cpp PRE-CREATION > > Diff: https://git.reviewboard.kde.org/r/117511/diff/ > > > Testing > ------- > > > Thanks, > > David Faure > >
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
