An analysis about a generic desktop application configuration management system

[Dave Cridland]

On Tue Apr 12 11:40:59 2005, Waldo Bastian wrote:
> On Tuesday 12 April 2005 00:44, Maks Orlovich wrote:
> > It would also be necessary to show that the list is non-empty, 
> and that any
> > examples are meaningful, and not better addressed by less-invasive
> > solutions (say XSettings)
> 
> XSettings doesn't touch on storage, it would solve the problem of 
> applications sharing common settings, it wouldn't solve the problem 
> of managing those settings. I would limit the use of XSettings to 
> visual appearance.

Does XSettings have to be anything more than a compatibility 
interface through to the shared configuration system?

In which case, do we simply take the existing XSettings keys, assign 
them to "new style" configuration keys, and then anyone can write an 
implementation which provides an XSettings interface through to the 
D-BUS (presumably) interface.

Then, going forwards, KDE/GNOME/Rox/etc get to use the new API to 
change them, get notifications, etc, completely ignoring XSettings 
itself if they so choose.

For example, we could prefix all of them by /~/org/freedesktop/ 
(Assuming /~/ is a magic configuration path to point to the current 
user's preferences). This means that Net/DoubleClickTime via 
XSettings is the same as /~/org/freedesktop/Net/DoubleClickTime

This potentially raises a requirement for "the" configuration system 
- either it needs to handle arbitrary binary blobs, or else it needs 
to handle those types used by XSettings.

Dave.