View source for 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


=== 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 [[#Trigger migration tool in main|above]] but implement functionality in library, run inside the starting application