KDE Core/Platform 11/Settings: Difference between revisions
Created page with '= Configuration systems = == DConf == DConf as a backend for KConfig would offer some nice features. Helio wants to try to implement it. Unlike the current .ini files it create...' |
|||
Line 34: | Line 34: | ||
== General == | == General == | ||
Having a dconf backend to KConfig is nice but doesn't mean a huge change. For application developers nothing would change due to this. | |||
What about QSettings? big problems with settings-groups, not power full enough for KDE. Can KConfig be merged with this? |
Revision as of 16:02, 3 June 2011
Configuration systems
DConf
DConf as a backend for KConfig would offer some nice features. Helio wants to try to implement it.
Unlike the current .ini files it creates one binary settings file that is used by all applications. A shell tool exists as well as a gtk settings editor.
Reading of settings is done via one mmaped file (read only). Therefor reading is fast. Writing happens via dbus.
There are notifications for changes of settings.
It features a hierarchy of settings like KConfig where user settings take precedence compared to system settings. The concept of locking is very similar to Kiosk immutable settings. In addition there are notifications if the locked state changes - that means activating a Kiosk immutable on a setting could immediately reflected in the UI.
There is an existing Qt library: https://gitorious.org/dconf-qt/dconf-qt
See also: http://live.gnome.org/dconf/SystemAdministrators
Problems could be:
There is no win/mac support. This requires keeping the old way with ini files a live or some investment to make dconf work or write other kconfig backends.
DConf stores its config in xdg dirs (.config).
QDesktopServices
It may make sense to split between application state and actual configuration settings. DConf could then handle the real settings whereas application state (unread mails in kmail) could be handled by the traditional ini files.
General
Having a dconf backend to KConfig is nice but doesn't mean a huge change. For application developers nothing would change due to this.
What about QSettings? big problems with settings-groups, not power full enough for KDE. Can KConfig be merged with this?