GitLab

Current state

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).

1. Extracts the settings of the theme (inside defaults file in the package) to their respective config files (kdeglobals, kwinrc, plasmarc, kcminputrc, ksplashrc) inside a special folder $XDG_CONFIG_HOME/kdedefaults
2. Reverts the entries of the user config files to the default

Since 5.22 plasmashell prepends $XDG_CONFIG_HOME/kdedefaults to $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_DIRS hierachy, those settings are also the new default value

Example

When I activate the breeze dark global theme

[Mouse]
cursorTheme=breeze_cursors

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

[Mouse]
cursorTheme=Breeze_Snow

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

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 plasma-apply-lookandfeel.

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

[KDE]
LookAndFeelPackage=lnfpackage.goes.here

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.}

Proposed solution

The current active look and feel theme is saved inside a file $XDG_CONFIG_HOME/kdedefaults/. 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.

Additional benefits

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 kdeglobals.

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 $location_of_current_lnf_theme/contents to $XDG_CONFIG_DIRS with no further step needed.