< Frameworks | Epics Contents 1 Migrating from KStandardDirs to QStandardPaths based resource access 1.1 Strategy by resource type 1.2 Requirements 1.3 Considerations 1.3.1 Operation Modes 1.4 Solution Brainstorming 1.4.1 Trigger migration tool in KConfig 1.4.2 Trigger migration in main Migrating from KStandardDirs to QStandardPaths based resource access Strategy by resource type Resource type "autostart" N/A Resource type "cache" Ignore, cache will be rebuilt by apps Resource type "config" Copy config from $KDEHOME/share/config to $XDG_CONFIG_HOME/ Resource type "data" Copy application data from $KDEHOME/share/apps/appname to $XDG_DATA_HOME/appname Resource type "emoticons" N/A Resource type "exe" N/A Resource type "html" N/A Resource type "icon" N/A Resource type "kcfg" N/A Resource type "lib" N/A Resource type "locale" N/A Resource type "module" N/A Resource type "qtplugins" N/A Resource type "services" N/A Resource type "servicetypes" N/A Resource type "sound" N/A Resource type "templates" N/A Resource type "wallpaper" N/A Resource type "tmp" Ignore, runtime resource Resource type "socket" Ignore, runtime resource General remarks Copying instead of moving should allow fallback to kdelibs4 based version of apps Use "kde" or "kde.org" (QCoreApplication::organizationDomain?) sub directory in target location? e.g. $KDEHOME/share/config/appnamerc -> $XDG_DATA_HOME/kde.org/appnamerc Requirements Frameworks 5 applications must be able to access resource without knowing about KDE paths Needs to work if applications run outside a KDE workspace session Cannot rely on some process run by startkde Easy to use for or hidden from application developers Do not run on every startup Needs to handle non-application resources Config files of libraries used by many applications, e.g. mailtransports Considerations Needs to be fast if executed at application startup Should be able to deal with huge amount of application data e.g. KMail1 local mail dir Needs to run before kconf_update runs Blocking concurrent migration Needs to block startup of the same application if migrating on per-application basis Needs to block all applications when migrating all resources in one go Operation Modes Likely needs two operation modes: Upgrade Fast enough for blocking startup In-process No change in usage or content, e.g. same config, other location Import (When Upgrade is not an option because of any of) Content change Functionality split, e.g. like KMail functionality being split out into agents Options no longer supported (user should be informed) Change of framework E.g. move from KConfig to something else, loosing Kiosk, env variable support, etc Too slow for hiding at startup, e.g. too many files Need/desire to give users the choice whether to migrate at all or to suspend/cancel Requires user input Solution Brainstorming krake: my recommendation is to go with explicit migration, i.e. the second option, but aid application developers as good as possible. Trigger migration tool in KConfig Pros Would be hidden to the application developers Cons Requires that applications use config before any other resource Applications with huge/complex data might not want copying. Would need to do it manually and bypass automated process some configurability for the automated process (e.g. globally installed config file for the migration code) Trigger migration in main Pros Makes time if invocation explicitly known to the application developers Allows to have API for tuning migration process e.g. not copy data, but retrieve data path and continue to use old location or delay data copying/importing to after GUI comes up Cons Requires application developers to modify main.cpp Needs to be documented, but removal of KApplication will require some porting anyway Could be checked for by Krazy or a similar tool (obviously only for apps hosted on KDE's infrastructure) Could be offered as a specialized KDE Framework, e.g. Tier 3 Integration. Either for use in the application code itself or for building a migration helper that is started by the application if necessary Could be furher split in a Tier 1 functional for detecting migration need and a higher Tier Integration for offering the migrator building blocks. Retrieved from "https://community.kde.org/index.php?title=Frameworks/Epics/StandardPathsMigration&oldid=34280" This page was last edited on 8 September 2013, at 13:34. Content is available under Creative Commons License SA 4.0 unless otherwise noted.