[linux-elitists] Re: Yet another mozilla atrocity

Karsten M. Self kmself@ix.netcom.com
Fri Oct 3 16:09:26 PDT 2003

on Fri, Oct 03, 2003 at 12:19:50PM +1000, Martin Pool (mbp@samba.org) wrote:
> On  2 Oct 2003, Jeremy Hankins <nowan@nowan.org> 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.

  <section path="My-Evolution/Weather">
    <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
    the project.

  - 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:

  <section path="My-Evolution/RDF">
    <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, ?,
    etc.) works.  

  - 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
configuration files.

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
technical user.

Again, you're throwing up a false dichotomy.


Karsten M. Self <kmself@ix.netcom.com>        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
Type: application/pgp-signature
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 mailing list