Frameworks/Epics/StandardPathsMigration

From KDE Community Wiki

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.