DConf configuration system

Avery Pennarun apenwarr at nit.ca
Thu Apr 7 21:15:25 EEST 2005

On Thu, Apr 07, 2005 at 08:00:38PM +0200, Waldo Bastian wrote:

> KConfig, as part of KDE KIOSK, allows you to mark individual keys (or even
> whole groups) immutable and KConfig will ignore any value for that key
> stored in the first layer, so the application will always use the (group
> or site) default for such keys.
> The question though is what is the most effective way to manage this. Do
> you want to store information about whether a default can be overridden by
> the user's personal setting together with the default setting itself (as
> KConfig does), or do you want to have a separate file that specifies which
> keys can be overridden, and which ones can not? The answer to that
> question depends on how you manage your settings as a whole I think. I
> like the KConfig approach because it makes it easy to create
> self-contained profiles that can be assigned to users. But maybe both
> should be possible if you want to micro-manage things (e.g. give a
> specific user the possibility to change his wallpaper while the default
> policy is to have locked down wallpaper settings)

This is a pretty good idea.  It maps rather closely to the way UniPermGen
works in UniConf; you have one UniConf tree with the actual settings, and
another UniConf tree with the permissions (sort of like Unix-style
permissions) for those settings.  Then you can stack pairs of
value/permission trees using UniListGen.

In other words, it looks like it would be possible to implement the KDE
Kiosk feature using current UniConf permissions features.

Have fun,


More information about the xdg mailing list