Feature added by: Cornelius Schumacher (cschum) Feature #311144, revision 1 Title: Alternative configuration backend for KDE applications Hackweek VI: Unconfirmed Priority Requester: Important Requested by: Cornelius Schumacher (cschum) Partner organization: openSUSE.org Description: It's sometimes annoying that desktop applications written with different toolkits or frameworks use different ways how to store configuration. This makes it harder to share configuration between applications, like sharing color preferences across applications written with different toolkits. It make it harder to write tools which work on configuration on a low level, like backup tools. It also makes it harder to share configuration between different machines, as for example to put configuration in an LDAP backend multiple configuration systems would have to be adapted to get a full desktop configuration supported. KDE applications widely use kconfig_compiler to create high-level native code to access configuration from a generic configuration description. How the actual config backend works is more or less encapsulated. It would be an interesting experiment to add the option to kconfig_compiler to create code, which accesses a different backend than the standard KDE KConfig one. It could for example generate code, which uses QSettings or dconf. This way KDE applications could ideally be moved to a different configuration backend just by a simple recompile. The other way around kconfig_compiler could also create code, which can natively be used by non-KDE applications, e.g. a Qt-only or a GNOME interface. I have no idea, if this would be useful for anything, but it would be fun to play around and explore the possibilities a bit. Maybe something good for a more consistent desktop experience could result, especially for a project as openSUSE, which contains a wide range of applications using different desktops frameworks. -- openSUSE Feature: https://features.opensuse.org/311144