DConf configuration system

[Avery Pennarun]

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,

Avery