Frameworks/Epics/StandardPathsMigration

From KDE Community Wiki
Revision as of 08:21, 4 July 2012 by Kevin (talk | contribs) (Add page about migrating KDE location files to XDG location files)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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


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, run inside the starting application