Skip to content

Allow vendor-specific defaults to be treated as defaults in kcm_kwin_effects

Aaron Rainbolt requested to merge (removed):master into master

Due to how plugins are set as "enabled by default" or not in kcm_kwin_effects, it is not currently possible for a vendor to set a plugin as enabled by default by setting a plugin as enabled in a kwinrc file located in an $XDG_CONFIG_DIRS path. This is because plugins are set as "enabled by default" or not in a place other than a kwinrc file (I believe it's looking in each plugin's desktop file), and KWin is currently designed to only look for whether a plugin is enabled by default in that location. This causes any vendor-set plugin defaults to be eliminated if the user clicks the "Defaults" button in the kcm_kwin_effects systemsettings module.

This patch causes KWin to take the contents of system-wide kwinrc files into account, causing vendor-specific plugin default settings to be honored. This makes the "Defaults" button in kcm_kwin_effects behave correctly.

As a sad side-effect, due to missing API functionality, it is no longer possible for KWin to determine whether the current plugin settings match the default settings or not, should we choose to honor these system-wide kwinrc files correctly. This is because there is no way to query the default value of a setting in KConfigGroup, to see if it matches the current value or not. This causes EffectsModel::isDefaults() to be rendered useless, as it is impossible (to my knowledge) for it to perform the job it was originally designed for. To avoid undesirable behavior, EffectsModel::isDefaults() will now always return "false" with this patch. This has the effect of making the "Defaults" button always enabled in kcm_kwin_effects, whereas it used to be grayed-out should the current config match the default config. (Whether it has any further effects or not, I do not know.) Until this "defaults querying" functionality is added to KConfigGroup, this function will be unfixable. If anyone has an idea for how to get around this problem, feel free to mention it. It would be awesome if we could avoid creating one bug in order to squash another, like this MR currently does.

BUG: 453752

Merge request reports