[linux-elitists] Re: Yet another mozilla atrocity
Karsten M. Self
Thu Oct 9 05:12:21 PDT 2003
on Wed, Oct 08, 2003 at 12:08:56PM +1000, Martin Pool (email@example.com) wrote:
> On 8 Oct 2003, "Karsten M. Self" <firstname.lastname@example.org> wrote:
> > http://www.gnome.org/softwaremap/list
> > 885 projects listed
> Heh, and 70,000 projects on sourceforge. :-)
The 885 projects listed are specifically GNOME projects. Dependent on
GNOME libraries. And at risk to GNOME project foulups.
Unless you had another point?
> > Secondly, a constant gripe with both GNOME and KDE is that I can't
> > consistently change, e.g.: an application's font settings FROM WITHIN
> > THAT APPLICATION. Example: changing Gabber's default chat window
> > fonts. No controls. I suppose that's buried somewhere in a global
> > GNOME configuration.... Konqueror is similarly infuriating (I realize
> > Konq isn't a GNOME app, I'm simply indicating that the brain damage
> > isn't GNOME specific).
> Nor can you change your screen resolution or network routing tables
> from within Gabber, although they both affect it equally much. Damn.
Martin: for the most part you've been contributing positively to this
conversation. Let's posit that there are reasonable scoping rules to
configuration settings: e.g.: settings which change _an_ applications
behavior, and more global settings which affect a superset of apps.
Specious. Non seq. <sigh>:
> Probably something should be done to make settings like this more
> easily visible when you're using a single application in isolation
> from the whole gnome ensemble.
This would be useful.
> > > Are you really saying that it is not acceptable for gui applications
> > > to have graphical configuration, only window managers? That seems a
> > > bit wierd.
> > For fucks sake, Martin:
> > PREFERENCES SHOULD BE ***FLEXIBLE***. THIS MEANS OFFERING THE
> > ***OPTION*** FOR ***BOTH*** GUI ***AND*** EDITOR BASED CHANGES TO
> > CONFIGURATIONS.
> Chill out, hey?
When I find myself making the same point, to the same person, multiple
times, I find it useful to highlight it sufficiently that I'm confident
I can demonstrate my opposite's being intentionally dense. Seeing as
someone else here is still rattling on about the same set of strawmen,
evasions, and non-seqs a week on, I've got a pretty strong basis for
conslusions in that case.
> You said that a graphical configurator "is acceptable for the
> _specific_ case of window managers" (your emphasis). That implies
> it's not acceptable to you for a paint program or graphical web
> browser to have a graphical configurator. You're welcome to feel that
> way but to me it seems a bit inconsistent and I'm not surprised you're
> having trouble persuading people.
A few points:
- I'm thinking some of this stuff out myself. I don't have all my own
answers. I change my mind. I find arguments persuasive.
- My meaning was perhaps less than clear. As a _primary_ mode of
configuring a tool, with few alternatives, GUI tools are highly
applicable for window managers. Which is to say: I've come to a
conclusion on this point. It's not that they're inappropriate (as
an exclusive or largely exclusive tool) for other applications. I'm
not prepared to state a conclusion there. That was my intent.
Most of the setting you're making in a desktop are inherently
graphical. It makes sense to (mostly) have GUI tools for
manipulating them. In the same sense that graphics programs are
similarly highly WIMP-driven (though I understand many high-end CAD
software relies strongly on keybindings and macros).
- Frankly, I'm not sure that the distinction between application and
window manager configurations is particularly clear. In both cases,
it's useful to have hand-editable configurations and to be able to
copy between systems (covered elsewhere, thanks), as well as to have
sensible graphical tools.
> As I've explained several times it's completely possible to change
> gconf settings through non-gui means. Continuing to angrily demand
> something that's already possible makes you look, um, very angry.
Let's get back to this just briefly.
Slight digression: DEB and RPM are two, largely comperable, packaging
RPM is defined according to specific library structures, the format
changes over time, and the libs must be available on a system in order
to manipulate (build, unpack, install) the package.
DEB is an 'ar' archive, with a few control files, and two tarballs. Its
unpackable on pretty much any system, including minimal boot floppies,
legacy MS Windows systems, Cygwin, other GNU/Linux distros, etc.
As a result of an architectural design decision to build a package
format out of available, least common standards components, users of
DEB-based systems have a great deal of flexibility in recovering or
rescuing systems from even highly borked states, with readily available
tools. I've done this more than once myself. And been quite grateful.
I'm leary, with the scars to show for it, of complex systems. Systems
which have dependencies between many parts. Systems in which large
numbers of components are dependent on a central core, particularly if
that core changes rapidly and drastically. And I'm really, really
concerned with tools that aren't documented.
Yes, you've pointed me to gconftool. And you pointed me to a website
Houston, we've got a problem.
- gconftool lacks a manpage, as previously demonstrated.
- gconftool lacks an info page, as previously demonstrated.
- The website you pointed me to includes an interesting developers
reference to gconf. It fails, however, to provide any useful
information on administering and configuring gconf.
- Fortunately, there *is* an "Other Resources" page, with a link to
- And this document even contains a specific section on gconftool.
Don't click on that just yet.
So: here I can find a description of gconftool, syntax, how to
refer to multiple configuration schemas, and examples of use,
archival, and all sorts of other useful information.
Um, Houston, that problem we were mentioning?
I'll make it easy. Just to spare everyone the trouble of having to
find a browser window, open that link, and read the page. I'll copy
the entire content, excepting titles and navigation elements, in
this email. You ready?
gconftool is used to control GConf from the command line.
OK, you didn't miss that.
Martin, that's the entire contents of that web page.
Got that: we've got a command line utility with no manpage ('Nix
standard, 30 years old), no Info page (GNU standard, 20 years old),
and no other evident online documentation of any sort.
And you were taunting me for not being able to find this?
Seriously? Sorry Martin: this is _not_ a documented feature. It's
a hidden hack backed by an "I'm just stating the obvious: this tool
exists" Microsoft Help style crap webpage buried on the GNOME
I'd say the GNOME projects got some priorities regarding documentation
and tools provision to work out.
I'm not holding a gun to your head or anything. Nope. I don't tell
people what to do regarding free software. I'll suggest. I'll
encourage. I'll even get a bit *HEATED* about the issue at times. But
I'm not paying your salary, and I'm not contributing to the code.
When I see shit, though, I call it.
I see shit.
Karsten M. Self <email@example.com> http://kmself.home.netcom.com/
What Part of "Gestalt" don't you understand?
Verio webhosting? Guaranteed downtime:
-------------- 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/20031009/cdff53db/attachment.pgp
More information about the linux-elitists