Look and Feel packages and first run
The currently active look and feel theme is saved in kdeglobals. Applying a look and feel theme does two things (disregarding desktop layouts for now).
- Extracts the settings of the theme (inside
defaultsfile in the package) to their respective config files (kdeglobals, kwinrc, plasmarc, kcminputrc, ksplashrc) inside a special folder
- Reverts the entries of the user config files to the default
Since 5.22 plasmashell prepends
$XDG_CONFIG_DIRS on startup. So the above two steps
- Apply the settings of the look and feel theme
- and because their also set in the first file in the
$XDG_CONFIG_DIRShierachy, those settings are also the new default value
When I activate the breeze dark global theme
will be written to
$XDG_CONFIG_HOME/kdedefaults/kcminputrc. The respective entry inside
$XDG_CONFIG_HOME/kcminputrc will be empty (reverted to default). So when reading the icon theme, the system will fall back to the file inside
kdedefaults. In effect the setting has been activated. The "default" button inside the cursor is deactivated since the active setting is the default one
If I now decide that I want rather use breeze snow cursor and activate it, my
$XDG_CONFIG_HOME/kcminputrc reads now
and the default button in the kcm is now active. When clicking it the setting is set to
cursorTheme=breeze_cursors which is the setting inside the file in
kdedefaults because is the most important (first) directory inside
$XDG_CONFIG_DIRS which contains this file and setting.
The problem boils down to that the settings are only exported to the
kdedefaults directory when a theme is applied via the kcm or via
For example a distro might create its own look and feel theme and wants to make it the default. To do so it can preconfigure it through
etc/xdg/kdelobals like so
However when logging in a user will see that the settings of the package have not been applied* even though the global theme kcm says the package is active! Because the the theme has not actually been applied, no config file on the system contains its settings.
*Some settings actually seem to be applied because a few places inside Plasma explicitly read settings of the active look and feel theme before reading from the normal config.
The current active look and feel theme is saved inside a file
During plasma startup this file and the current active look and feel theme are read. If they don't match or the file does not exist, this is the that the
kdedefaults folder needs to be regenerated which is done by calling into the relevant code.
This new file is added to ensure this work is only done when really needed.
How to not break users
Note that we only need the
kdedefaults folder to activate the theme for new users, since their config files inside
$XDG_CONFIG_HOME are empty, so reading will fallback to
kdedefaults. For existing users recreating this folder once after an upgrade will do nothing, the same content will be written to it. If they had modified a specific setting, it is not overridden by this process, since their actual config files are not touched.
Because this ensures that normal reading of settings respects the look and feel theme we can drop the code paths that do it manually (an example of this is our platform theme).
This also would allow to use to finally drop the
kde4breeze update script, since we have a proper system that writes colors to
Long term plan (Plasma 6)
A much easier system than the current one and simpler solution to this solution involves how settings are stored inside a look and feel theme. Because of this it is only viable for Plasma 6 where we can break the package format.
Currently the settings are specified inside the
defaults file in the package. Each top level config group in this file corresponds to a config file, each sub group to a top level config group in a config file. Because of this the settings need extraction.
My idea instead is that the packages directly contain the config files. This would remove the need of extraction and the
kdedefaults folder. During startup plasma would just prepend
$XDG_CONFIG_DIRS with no further step needed.