Re: Configuration

[dominik vogt gmx de]

On Fri, Nov 29, 2002 at 06:53:11PM -0500, Havoc Pennington wrote:
> On Sat, Nov 30, 2002 at 12:04:35AM +0100, dominik vogt gmx de wrote: 
> > That does not work.  The window manager does not necessarily run
> > on the same machine as the desktop environment.  That is one of
> > the strenghts of X and I would not be willing to give it up.  The
> > best way in my eyes is to implement some kind of configuration
> > database on the X server.
> 
> I think this issue is orthogonal, I'll list some various approaches to
> configuration and explain how any of them could get this right or not.
> 
> 1) We have an app "gnome-settings-daemon" the purpose of which is to
> mirror persistent configuration (e.g. from a config file) to transient
> per-display settings (e.g. Xkb state, or an X property indicating the
> length of the double click timeout, or the Xft X resource settings).
> 
> In line with that, we could define transient state in EWMH and leave
> persistent storage to the desktop. 
> 
> Concretely this approach is:
> 
>   - desktop stores a setting "foo" on disk and sets _NET_FOO hint on
>     root window with current setting (or instead of a hint uses some
>     generic "database" such as X resources or XSETTINGS)
> 
>   - to change "foo" you change the desktop setting then the desktop 
>     mirrors it to the X server and the WM picks it up
> 
> We have done this in GNOME before, my view is that it introduces one
> of two problems:
> 
>   - the WM is dependent on the desktop for configuration
> 
>  or
> 
>   - the WM *also* stores "foo" on disk, and the WM config tool
>     modifies that copy, but the desktop overrides any setting from the
>     WM-specific config file. I find this confusing and messy.
> 
> I'm not a big fan of either of those problems.
> 
> Anyway, the approach clearly works with WM/desktop on separate machines.
> 
> 2) The "dlopen()" proposal is: desktop control panels know how to modify
> the WM's persistent store of "foo" on disk. This could involve simply
> changing the files, in which case it assumes the WM and control panel
> share the same home directory. I consider that sane, but if you want
> to avoid it, you could implement a way for the control panel to
> communicate with the WM via client messages and ask the WM to change
> the setting and persist it to disk. Then it would all go via the X
> server. So the "dlopen()" approach can easily support WM and control
> panel on separate machines, as long as a given WM supports a mechanism
> for that.

Apart from the fact that dlopen() does not work between different
amachines, I think it is also too restrictive on your build
environment.  To get it working at all, you probably have to use
libtool, autoconf and automake which is not so easy to set up.
And finally, accessing the files of another process or even user
creates permission and security issues.

> 3) Another possible proposal is: the WM sets _NET_FOO, and also accepts
> _NET_FOO messages which cause the WM to modify the value for _NET_FOO
> that's persisted to disk. This is pretty much how
> _NET_NUMBER_OF_DESKTOPS works right now and you might also implement
> the dlopen() backend for a particular WM to work this way.
> 
> This plainly works with WM/desktop on separate machines.
> 
> 4) Do 1) or 3) only have a generic way of storing settings on the root
> window such as XSETTINGS or X resources, instead of making up a
> custom property for every setting.
> 
> I don't like this as a permanent solution because I think the
> permanent solution should be a more capable config system, as in
> approach 5) - but XSETTINGS is a simple thing intended as a temporary
> GTK/Qt hack that might be usable in the WM context.
 
> 5) Of course the blue sky approach I mentioned is to simply share a
> configuration database, along the lines of gconf. My opinion is that
> this should/must be network-transparent (in fact gconf is), and may
> even be able to use X client messages as a transport to avoid opening
> any new ports (gconf doesn't do this but could). So it could also 
> work with WM/desktop on separate machines, there are several possible 
> ways to implement that. The design of this system is a *lengthy* topic
> so I won't go into it too much.

How does gconf work?

> Anyway, considering these 5 approaches, my opinion is that any of them can
> be made to work when WM and desktop are on separate machines, so
> really we still have to decide between them on other grounds.

I prefer one of the approaches that works with plain X and does
not force the window manager to implement yet another interface.

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, dominik vogt gmx de
Reply-To: dominik vogt gmx de