Configuration/setting concept draft

I believe it is not just me who gets mad every time an update surprisingly change previous configurations/settings or functions. My idea to reduce such problems bases on several existing configuration concepts of hardware and software.

Level based
There should be a level-based system, similar to hardware like network switches. There is e. g. a “factory default”, a “user default” and a “temporary” configuration, which will be set to “user default” after restart. At KDE there could be a “factory” and a “user” configuration. Additional levels are possible, e. g. “admin”, “group”, “new”, “test”.

Difference based
The configuration of lower level should not contain the complete configuration, instead the “factory” configuration always include all parameters and the “user” configuration includes changed parameters only. Therefore new parameters can be added and default parameters can be changed, without deleting the users changes.

Enterprise administration
It should be possible to define a global (for all users) configuration and a local configuration. This might be very helpful for administration, not just for several users within the same computer, but also for all users within an enterprise. By deleting the users configuration the administrator is able to set a working default.

Additional to the above mentioned points, this concept could be designed based on “config”-files, but also as an database. I could even imagine a central masster-configuration, where the settings of all programs are inside, include a documentation. Changing one parameter would change the setting of all programs which use the same parameter, if no specific configuration has been set for the single program. This would exceed the above mentioned concept, but could be a huge improvement.

1 Like

In fact KDE’s KConfig system already has everything you describe here except for “Database”. :slight_smile:

Clearly its documentation isn’t anywhere near good enough if you weren’t able to discover this for yourself, though.

The specific issue you’re having where an update changes the default settings isn’t actually related to any of this, though. It’s caused by the fact that default settings are generally set in code, rather than written to disk. Therefore, when the default (in code) changes, you get that change because you don’t have a local config file with a different value in it.

It’s a generic issue that definitely needs looking at, because people do get annoyed a lot when system updates change default settings and result in de facto behavior changes to people who were using the prior default settings.

See also Consider permitting the user to choose whether they want changed defaults to take effect on upgrade (#11) · Issues · Plasma / Plasma Workspace · GitLab.


Visiting whether a database might be beneficial might be best in a separate post, if you can provide some concrete examples. It’d obviously be an improvement over some text files, but due to the work necessary to port them to one and change the KCMs to interact with it, it might be worth detailing more comprehensively.

Thank you for the replies so far. I will prepare an example to make the proposal more clear. Due to a lack of time, this could take some additional days.

This post is what I was looking for, but couldn’t find when I created my post.