gconf brain death (was Re: [linux-elitists] Yet another mozilla atrocity)

Martin Pool mbp@samba.org
Wed Oct 1 16:56:11 PDT 2003

On  1 Oct 2003, "Karsten M. Self" <kmself@ix.netcom.com> wrote:
> on Wed, Oct 01, 2003 at 11:53:05AM +1000, Martin Pool (mbp@samba.org) wrote:
> > On 30 Sep 2003, "Karsten M. Self" <kmself@ix.netcom.com> wrote:
> > 
> > > Best I can tell, gconf is largely bug-for-bug compatible on all
> > > points, though I admit my aquaintance with it is quite casual.
> > 
> > I earnestly hope this spawns a GconfTroll on Slashdot.  The
> > combination of just enough truth to make it plausible, self-righteous
> > ignorance, and criticism of any passing similarity to Windows would be
> > right at home.
> Consider:
>   - I'm hardly a naive user.  I don't follow GNOME closely.  I don't,
>     for the most part, use it.

You are welcome to not know about GNOME or not use it much; just
please refrain from prejudiced criticism.  gconf ought to be, and in
my experience is, something that stays in the background without being

> And what's your basis for assuming I hadn't looked?

Well, in my experince, looking for binaries containing the string
"gconf" is a good way to find command-line tools to deal with gconf.
So is "dpkg -L gconf2|grep bin", and so is Googling for "gconf".  Had
you done any of these things, you would have found it.  But I suppose
you just search for things in a different way than I do.

Almost by definition command-line tools are something you need to know
about from reading documentation, rather than being immediately
obvious in a menu.

> Note GNOME's blatent disrespect of following the 30 year-old
> standard of providing manpages for packages.

I think GNOME choosing to use Docbook rather than manpages or Info is
a justifiable decision given their target users, but that is a whole
other thread.

It sounds like your objections are really

 - There's no manpage for gconftool.  Fine; file a Debian bug and
   somebody will write one eventually get fixed eventually.

 - Some of the developer documentation for GNOME is not installed in
   the Debian packages, but is available from their web site.  GNOME
   is hardly alone in this.  File a bug; somebody will package it up.

Neither of these mean that gconf is buggy or poorly designed.

> > One way in which gconf is superior to traditional dotfiles is that
> > change notifications are broadcast, rather than relying on restarting
> > the program or the user reloading their configuration.  
> This is a program/application issue, not a fundamental advantage of one
> system over the other.  gconf may be able to utilize sockets rather than
> watching files, but the fundamental problem isn't insurmountable.

I think any tool which set out to solve the same problems would
converge on a design rather like that of gconf.  gconf benefits from
observing the good and bad points of xrdb, the Windows registry and
other systems.

Consider the traditional Unix alternative for configuring X programs:
X resources:

In almost all cases, the resources only take effect when the program
is started.  To try out a new setting, you need to exit the program
and restart it.  In some cases you might need to exit X and log in
again.  Not very friendly, is it?  The similarity to "Would you like
to restart your computer now?" is painful.

You can edit ~/.Xresources with a text editor, which is good.  You can
similarly edit gconf via gconftool, and you could trivially wrap that
up as an editor mode.

Unfortunately you can *only* edit Xresources from a text editor.  When
for example choosing colors, you need to pick a color from something
like xcolorsel, type it into the file, save it, reload your resources,
restart the program, and see if you like it.  Fonts are even worse.

For programs that do have settings, the obvious and friendly way is to
allow the user to change them interactive and then have those changes
remembered.  gconf supports this with minimum effort by the
application programmer.

There's no description of what keys or values are valid, except
perhaps an informal one in the program's manual.  If you make a
mistake, your entry is at best ignored, and at worst the program is

Doing anything more than trivial customization requires a detailed
knowledge of how X resources work.  Can a non-expert explain the
difference between '*' and '.', or between 'emacs' and 'Emacs'?  By
contrast gconf has good gradual disclosure: most users can just use
their application's preferences file, but if necessary one can go
through gconf-editor or gconftool and see the underlying structure
without being totally confused.

There are similar problems with program-specific dot files.


More information about the linux-elitists mailing list