Frameworks/Epics/StandardPathsMigration

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.