Re: Configuration

[Havoc Pennington <hp redhat com>]

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.

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.


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.

Havoc