Configuration

[Havoc Pennington <hp redhat com>]

Hi,

The window manager spec has consciously avoided the issue of
configuration in the past. However, this limits the ability of
alternative window managers to fully work with desktop environments.

In GNOME, there are a variety of solutions currently in use:

 - in a couple places, the WM spec has sort-of dealt 
   with configuration, e.g. "_NET_NUMBER_OF_DESKTOPS" 
   messages, so that's used to backend the pager 
   config option

 - for something like "current WM theme" or "focus mode" GNOME has a
   dlopen() module it can load for each WM that changes those things
   for that WM. In practice only a metacity dlopen() module exists
   right now. Of course this approach requires writing code for each
   desktop-WM pair.

Here is a concrete example we're currently facing. We are implementing
a "visual bell" feature that flashes the screen (or optionally the
frame of the window that sends the bell) in response to Xkb bell
events. IMO the best place to stick this feature is in the WM,
especially because of the desired flash-the-frame effect.  (Though I
recognize it could be done outside the window manager, it seems silly
to have a "visual bell daemon.")

So there are config options for the bell style and whether to use the
visual bell at all. These are presented to users probably in the
Accessibility, Keyboard, and/or Sound control panels - they don't make
sense in a "window manager" control panel.

It seems a very special-purpose thing to put in a spec. But if we
don't, effectively GNOME requires metacity, or at least people have to
write the dlopen() config module for each WM they want to use.

My dream solution:
  
 - we make GConf or equivalent desktop-independent, and just
   standardize the config options themselves, and anything 
   including any WM can read them

But, that's more long-term.

My opinion right this second is that we should not load up the EWMH
with a ton of _NET_CONFIG_VISUAL_BELL etc. root window properties, and
we should go with the dlopen() module approach. This will definitely
make it harder to use alternative WMs. But we should be aiming for a
standard config system over the 2-3 year timeframe, and thus it would
be better not to create a giant clutter of root window properties.

(I know even if we have a standard-across-desktops config system not
everyone will use it, but we can at least write little
config-system-to-WM-config bridge daemons, which is a per-WM task,
instead of a per-WM/desktop-pair task. And some people may use it
directly.)

Using the dlopen() approach doesn't require action on the part of
anyone on this list, but I wanted to post my line of thinking in case
anyone has better ideas.

Havoc