Re: Configuration

[Havoc Pennington <hp redhat com>]

On Sat, Nov 30, 2002 at 01:23:19AM +0100, dominik vogt gmx de wrote: 
> 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.

The point is simply that you have a code module for configuring each
window manager - pretend it's compiled in, not dlopen()'d, as the
dlopen() is beside the point.  The dlopen() usage is all in GNOME
(which already heavily relies on dlopen()).

You have a vtable like this:

struct
{
  void (* set_current_theme) (const char *theme_name);
  void (* set_foo) (int bar);
  int  (* get_foo) (void);
} WMConfigurationVTable;

You implement the vtable for each WM, the control panel uses that
vtable instead of hardcoded knowledge of that WM. Right now it's only
implemented for Metacity so the GNOME WM control panel only works with
Metacity.

One point about this is that it does not involve writing specs (or
modifying window managers in any way), it puts all the burden on
people to write modules that come with GNOME.
 
> How does gconf work?

It has a little daemon that caches configuration data, processes
changes to it, and sends out notification of changes. Apps talk to the
daemon via the network (unix domain, TCP, SSL, whatever). It's a minor
modification to the architecture to use a hack over client messages as
the transport, rather than a dedicated socket - I consider that about
1% of the design issues, it's a reasonably complicated problem.

There's a writeup in this document:
  http://www.linux.org.uk/~ajh/ols2002_proceedings.pdf.gz
also see:
  http://www.gnome.org/projects/gconf/

But again, I don't think this is the place or time to debate a full
config system, though I hope it will be the right time soon.  First we
have to have a decent IPC mechanism.
 
> I prefer one of the approaches that works with plain X and does
> not force the window manager to implement yet another interface.

All the approaches can basically work with X or <insert your IPC
mechanism here>. The important differences in the approaches include
who persists the config data, where the master copy of the config data
lives, who has to do the work of writing the glue between each desktop
and each WM, etc.

I would certainly propose using X for any short-term hack protocols,
and I'm only suggesting short-term hack solutions for this problem at
this point.

Havoc