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

Solution Brainstorming

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.