An analysis about a generic desktop application configuration management system
dave at cridland.net
Tue Apr 12 14:39:08 EEST 2005
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.
More information about the xdg