[linux-elitists] Re: Yet another mozilla atrocity
Mon Oct 6 20:37:56 PDT 2003
On 4 Oct 2003, "Karsten M. Self" <firstname.lastname@example.org> wrote:
> I think the criticisms of gconf, and GNOME in general, are reasonably
> clearly stated.
They seem to be
1- gconf doesn't use plain text files for storage, and doesn't like
you editing them by hand.
2- gconfd is more complex than it needs to be to solve the parts of
the problem Karsten &co think are important.
3- GNOME leans towards leaving out configuration options that aren't
clearly necessary, and this annoys some power users who like
4- GNOME has more coupling than other programs: GNOME programs need a
pile of libraries installed and they like to have the whole desktop
Is that a fair summary?
I agree 1 is unfortunate, but I think it is a reasonable price to pay
to get other advantages, such as being able to notify applications of
Configuration options are seen more as part of the application's state
than as a direct part of the user interface. GNOME is far from the
only free software application to store settings this way. One that
springs to mind is Mailman, which stores many things as Python
pickles, and presents both a web-ui and programmatic interface for
I think if you agree with the goals, such as being able to change
settings from inside a program and having settings apply to multiple
programs, then 2 is not true. gconfd is a reasonably clean approach
to storing a tree database and notifying of updates. It could be
3 is a really interesting digression from historic unix practice.
Some posts in this thread seem to want preferences for their own sake,
because the person likes changing things. I suppose the question is:
is "one size fits all" always a contradiction?
It might be that people care more about some software than others. My
emacs is moderately customized, but I'm quite happy that the GNOME
clock has only four options.
> The fundamental problem is one which is best stated, IMO, in the
> recently published white paper "Cyber Insecurity", Greer et al. Yes,
> the paper addresses Microsoft. Its principles are generalizeable,
> however, particularly this paragraph on page 13:
> Tight integration, whether of applications with operating systems or
> just applications with each other, violates the core teaching of
> software engineering, namely that loosely- coupled interfaces make
> maintenance easier and life-cycle costs lower. Academic and
> commercial studies supporting this principle are numerous and
> long-standing. Microsoft well knows this; Microsoft was an early
> and aggressive promoter of modular programming practices within its
> own development efforts. What it does, however, is to expressly
> curtail modular programming and loose-coupling in the interfaces it
> offers to others. For whatever reason, Microsoft has put aside its
> otherwise good practices wherever doing so makes individual modules
> hard to replace. This explains the rancor over Prof. Ed Feltens
> Internet Explorer removal gadget just as it explains Microsofts
> recent decision to embed the IE browser so far into their operating
> system that they are dropping support for IE on the Macintosh
> platform. Integration of this sort is about lock-ins through
> integration too tight to easily reverse buttressed by network
> effects that effectively discourage even trying to resist.
> Read that until you get it. I see strong echos of this practice within
> GNOME especially -- it's a reason I find it very, very hard to trust
> Miguel, it's why I don't generally like design decisions GNOME makes.
> For the most part, where I like GNOME apps it's *despite* rather than on
> account of many of the GNOME tight-integration features.
It's an interesting comparison, although I'm starting to think
Godwin's law ought to apply to comparisons to Microsoft.
Of course Microsoft are intentionally trying to lock people in, and
using monopoly power to do so. I don't think either of those apply to
Many people seem to use some GNOME-based applications on non-GNOME
desktops, or use part of the desktop. (I often disable Nautilus,
which is reasonably straightforward.) I sometimes run Metacity, rxvt
and emacs, and nothing else. OK, I can hear echos, but it's a long
One very good thing about Gentoo is probably increased testing of
random combinations of software configuration options. Just the other
day I fixed a bug asking for the ability to build with only gtk, not
> While wer're talking gripes:
As Jesse said, these are just bugs. Most software has them, and I
don't see any systematic reason for them. File non-incendiary bug
reports and they will probably be fixed.
> > If software authors want to address an audience who does not enjoy
> > editing dot files in vi, who are you to tell them not to?
> If we want to point out the very obvious flaws and problems in a scheme,
> who are you to tell us to shut up?
I guess I would respect it more if you could think of a better design,
rather than just complaining. The ones that have come out
(e.g. Nick's "just poll every second", Don's "put it all in one
configuration file") have problems.
> GNOME's development team is welcome to follow any idiotic path of
> development they wish to. They are not welcome to tell the rest of the
> community to stuff it *and* shut up. "Stuff it" is acceptable, but
> that's a two-way street. It's not a particularly rewarding journey.
I'm not sure what you mean by "stuff it" here. If you never use GNOME
applications, the debate is irrelevant. If you want the people
writing e.g. Pan or gnumeric to do things your way, they you need to
come up with a concrete better design, and preferably working code.
> > It's strange and unfortunate to have GUI software that can only be
> > configured through a text file, just as it would be s & u to have a
> > daemon that could only be configured through a GUI.
> There are happy mediums. You're presenting a false dichotomy.
> Two applications which spring to mind are w3m and WindowMaker. While
> neither may be mainstream or particularly Joe-sixpack oriented, both
> have the following advantages:
OK, this sounds like the current best design for interactively
configured Unix applications. It's certainly a long way ahead of
> - They use plain-text, human editable configuration files.
XML is human editable, though not as easy as a simple line-based
format. emacs and vi understand XML, and at least it's a standard.
> - They have very intuitive, easy to use, configuration utilities.
> WMaker's is, in fact, GUI (WPrefs). In the _specific_ case of a
> window manager, I find this acceptable. For w3m, the 'o' key brings
> you to a menu-driven config screen, covering a wide range of useful
> options. Noting Joey Hess's comment that preferences should be
> searchable, I'll note that standard vi search ("/expression", n, ?,
> etc.) works.
Similarly, GNOME applications have configuration dialogs that are
generally friendly and easily available. Most people need never know
gconf is under the bonnet.
Are you really saying that it is not acceptable for gui applications
to have graphical configuration, only window managers? That seems a
I agree that preferences should be searchable. I love that in emacs.
> - In both cases, copying a file (~/.w3m/config) or directory tree
> (~/GNUstep/) transfers all the appropriate settings between systems.
> Preferences portability has always been a hallmark of 'Nix systems,
> and the loss of this under the current GNOME scheme is a very
> serious step backward.
Does this in fact not work with gconf? It seems to work for me. If
not, file a bug.
Here are some problems with w3m, from brief experimentation. They're
typical of this kind of approach where you just read and write a
- Syntax errors in the configuration file are silently ignored.
- If I change an option in one instance, it is not propagated to the
others until I quit and restart them, losing some state.
- If I save the options from one instance, the changes overwrite each
other. In particular my persistent browser history is lost -- we
are losing (slightly) valuable user data.
- OK, I can edit the configuration file by hand, but I need to
restart the program to make my changes take effect.
- There is no consistency between applications; I have to adjust my
color preferences through a different mechanism in links, w3m, tin,
and mutt. For applications of this vintage this is expected but for
modern GUIs it's lame.
gconf fixes, or mostly fixes, these problems. I think that is a
reasonable tradeoff when the price is just using gconftool rather than
> > If you choose to use a command-line music player it's perfectly
> > scriptable from the command line. But it would be a bug for a
> > graphical player to require you to hand-edit configuration files,
> > because it makes the application inconsistent.
> I don't believe anyone here is *mandating* use of editors on
> configuration files.
I think this was in the context of xrdb, where editors are the only
> What I am *requesting* and *strongly recommending* is that configuration
> files follow conventions of location (so you can find the damned
Looking under ~/.gconf/ does not seem incredibly onerous.
> and be both comprehensible and modifiable by a reasonably
> technical user.
Well, I suppose I just think that a reasonably technical user can
learn to use gconftool. It is not that hard, especially given that
you can use that knowledge across many applications, and it avoids the
need to work out the syntax for every single application.
More information about the linux-elitists