[linux-elitists] Re: Yet another mozilla atrocity

Jeremy Hankins nowan@nowan.org
Tue Oct 7 07:46:29 PDT 2003

Martin Pool <mbp@samba.org> writes:
> On  5 Oct 2003, Jeremy Hankins <nowan@nowan.org> wrote:

>> I can easily see the point of a lib that provides a standard syntax
>> for config files, is capable of setting policy (e.g., read global
>> config first, and allow it to override the per-user config), and
>> takes care of locking in a consistent, predictable way.
> So tell me: if you're going to allow people to edit the
> configuration files with any old text editor, then how are you going
> to do locking?  You can't use file locks or atomic replace.

I carefully didn't use the terms "robust" or "reliable" but instead
referred only to consistency and predictability.  I'm open to being
convinced otherwise, but I strongly suspect that would be enough.  Do
you really need robust locking for your wm config file?

> How do you report syntax or semantic errors to the user?
> Traditional tools write to stderr (often to ~/.xsession-errors), and
> hope the user can find the message.  If some of the configuration
> items can't be read because the file is corrupt, should they
> suddenly pop back to their default values?

Are you claiming that gconf solves this problem?  I don't know what
your point is here -- nor, frankly, what's wrong with reporting to
stderr, unless it's completely illegible.  Have you looked at a
.gnome-errors recently?

> How does the application know when to reload the changes?

Easy: don't.  Nice example of giving up a little bit of functionality
in order to save big on complexity.  I just don't see the point,
especially when any solution is going to be complex enough to be
buggy, and thus even more confusing to users than leaving well enough

> What happens if the application needs to store an option while it's
> open in the editor?  Another race.

Yup.  And you get warned when you go to save the file, and you have
the choice of backing out whatever changes the gui made.  Simple,
predictable, and flexible.

> Don said that each application should have one dot file called
> ~/.${app}rc.  OK, that does make it easy to find and copy around.
> But what about options that apply to more than one application?  If
> you have a ~/.guirc, ~/.printerrc, ~/.networkrc, ~/.apprc then you
> converge on a similarly confusing state.

Is this a real problem or just a prediction?  I have no problem with a
.gtkrc, nor do I think it's terribly confusing.

> Here's an example of a power-user task: people might like to
> synchronize their options between intermittently connected machines.
> I do this using Unison and emerge, but this doesn't work for people
> who don't want to see the guts of the configuration file.  gconf, by
> having mtimes on options, has the possibility of a good solution in
> the future.  In the interim, you can do it by either copying the
> files or using gconftool.

Again, vapor.  Copying files is certainly no easier with gconf (ever
tried it while gconfd is running?), and gconftool is no less a
power-user tool than unison & emerge.

>> Yes, of course.  Anything graphical needs to be dumbed down.  Keep
>> those (l)users in their place.  As far as I can tell, this is the
>> core of your position, yet it's completely without support.
>> There's a problem with the configuration interface?  Well, you
>> shouldn't really be using that anyway.  Configuration is only for
>> the mentally ill.
> I think you have a chip on your shoulder here.

Perhaps so.  But as far as I can tell the last two sentences are a
perfectly adequate summation of Jeff's position.

> My car doesn't have a choke control.  That isn't because the
> designers were dumb, or thought I was dumb.  It's because they were
> smart enough to make it automatically adjust to conditions, and
> indeed it has never failed to start.  At its best, GNOME achieve a
> similar elegant simplicity.

If that is what gnome is at its best then I'd love to see it there
someday.  Perhaps then it would be something I'd enjoy using.  For the
time being, though, my complaints seem on-target.

Jeremy Hankins <nowan@nowan.org>
PGP fingerprint: 748F 4D16 538E 75D6 8333  9E10 D212 B5ED 37D0 0A03

More information about the linux-elitists mailing list