Frameworks/Epics/StandardPathsMigration: Difference between revisions
< Frameworks | Epics
(Folding two similar section into one) |
|||
(One intermediate revision by the same user not shown) | |||
Line 96: | Line 96: | ||
** Needs to block all applications when migrating all resources in one go | ** 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 === | === 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 ==== | ==== Trigger migration tool in KConfig ==== |
Latest revision as of 13:34, 8 September 2013
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
- Content change
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)
- Requires application developers to modify main.cpp
- 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.