Migrating from KStandardDirs to QStandardPaths based resource access
Strategy by resource type
- Resource type "autostart"
- 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"
- Resource type "qtplugins"
- Resource type "servicetypes"
- Resource type "templates"
- Resource type "wallpaper"
- 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
- 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
- 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
Likely needs two operation modes:
- Fast enough for blocking startup
- 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
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
- Would be hidden to the application developers
- 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
- 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
- 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.
This page was last modified on 8 September 2013, at 13:34. Content is available under Creative Commons License SA 4.0
unless otherwise noted.