Look and Feel packages and first run
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).
- 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
- 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.