[linux-elitists] Re: Yet another mozilla atrocity
Karsten M. Self
Fri Oct 3 16:09:26 PDT 2003
on Fri, Oct 03, 2003 at 12:19:50PM +1000, Martin Pool (firstname.lastname@example.org) wrote:
> On 2 Oct 2003, Jeremy Hankins <email@example.com> wrote:
> > gconf-editor is a gui, iirc, and gconftool isn't exactly a substitute
> > for a text file. But in any case, I understand that. gnome is
> > designed for users who like clicky interfaces & eye candy. Different
> > people have different priorities; I have no problem with that, and I
> > acknowledge that there is a niche that gconf fills. What annoys me is
> > when *I* have to deal with it.
> So don't deal with it. Don't use software that uses it.
I'm going to pick up the non-sequitorishness of this all again.
I think the criticisms of gconf, and GNOME in general, are reasonably
clearly stated. Though there appear to be those who can't or won't see
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.
The whole nature of Microsoft's lock-in, tight coupling, and their very,
very clear demonstration that the *do* in fact "get it" regarding
modularity is something that's been clear to me for most of the time
I've followed GNU/Linux and free software explicitly. One of the key
texts in my "Free Software Primer" is from Microsoft Press: Steve
McConnell's _Code Complete_.
If there's a two-word encapsulation of _Code Complete_, it's "code
modularly". Again and again and again, the _best_ free software
projects follow this principle. Mozilla/Firebird are finally headed
down this path. OpenOffice.org is not, and with Sun staggering, this
makes my assessment of OOo's long-term viability uncertain. Not the
message I want to take to organizations for which I'm presenting OOo as
a feasible, long-term viable alternative to MS Office.
The objection to GNOME's gconf isn't *just* an "old fart's" attitude.
It's a deep understanding of what makes for good, viable, long-term
tenable, quality software.
Again: I don't particularly use GNOME, GNOME desktops, or GNOME apps.
I've had a glancing familiarity with all of the above (I like to explore
aspects of the GNU/Linux desktop and application space). Two specific
examples come to mind, both of which I find very unacceptable:
- In Galeon, a setting *specifically made* through the configuration
menus, fails to take hold. The alternative text file
(~/.galeon/mozilla/galeon/user.js) documented as specifically
intended for overriding the preference, fails to apply the change.
The only way to make the change is via gconf, and the only reliable
way to modify the gconf setting is via the gconf-editor tool.
- In Evolution 1.0.5, the "Summary Page" has a "My Weather" feature.
First gripe: I hate the "My Foo" school of attribute naming. It's
either "Weather", or "System name" (my computer has a name, damnit).
"My Foo" is patronising to the extreme.
The locations for which weather information are available can be
configured through a menu dialog. One thing that *can't* be done
through this dialog is to order the locations -- these have to be
added one at a time, in the reverse order in which you want them to
appear on the dialog. If you get the order wrong, you have to
delete your selections and start over again.
Naturally, this information is stored in a flat text file,
~/evolution/config.xmldb. So here's the exercise for the reader:
- How many stations am I monitoring, what are they, and in what
order are they displayed? The bonus question is: what the hell
is the encoding here?
- What units am I displaying information in, and what the hell do
"units" refer to?
- What is my refresh period, in what units? Note that this last is
a common gripe to many programs which specify "delay" in units
varying from thousandths of a second to hours, but fail to specify
*the fucking unit* for the value in either configuration file
notes or documentation. GNOME are following well established, but
still deplorable, precedent here.
<entry name="stations" type="string" value="4b41504320213c2d2d3e21204b445041
<entry name="units" type="long" value="0"/>
<entry name="weather_refresh_time" type="long" value="600"/>
While wer're talking gripes:
- GNOME configuration dialogs which can't be resized. If I have more
than a very small number of selections in a dialog, I *much* prefer
to be able to resize the dialog to maximum monitor height (I've got
a windomaker hotkey that toggles this specifically). GNOME is
bug-compatible with Microsoft in creating many *very* cute dialogs
which *cannot be resized*. Yet another very major annoyance with
- I note that the news feed picker replicates the problem of not being
able to reorder feeds. And that the value storage is a similarly
opaque hex representation. While we're at it, how many feeds have I
selected, in what order:
<entry name="rdf_urls" type="string" value="687474703a2f2f736c617368646f742e
<entry name="rdf_refresh_time" type="long" value="600"/>
<entry name="limit" type="long" value="10"/>
> 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?
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.
> 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:
- They use plain-text, human editable configuration files.
- 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, ?,
- 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.
> 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
What I am *requesting* and *strongly recommending* is that configuration
files follow conventions of location (so you can find the damned
things), and be both comprehensible and modifiable by a reasonably
Again, you're throwing up a false dichotomy.
Karsten M. Self <firstname.lastname@example.org> http://kmself.home.netcom.com/
What Part of "Gestalt" don't you understand?
Bush/Cheney '04: Putting the "con" in conservatism
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
Url : http://allium.zgp.org/pipermail/linux-elitists/attachments/20031004/c72fcbe8/attachment.pgp
More information about the linux-elitists