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 tool 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)

Trigger migration code in main

See above but implement functionality in library, basiclly an additional KDE Framework with the purpose of aiding application developers who already use KDE library technology.