[Desktop_architects] Printing dialog and GNOME

[Christian F.K. Schaller]

On Mon, 2007-02-19 at 14:14 -0800, Linus Torvalds wrote:
> [ away for the long weekend, am back now ]
> 
> On Mon, 19 Feb 2007, Christian F.K. Schaller wrote:
> >
> > So I added your patches to bugzilla this weekend, in an attempt to be
> > constructive on my own part also. So far two of them are merged and
> > based on the discussion I see that a 3rd one will probably go in today.
> > 
> > If you are interested the tracker bug is here:
> > http://bugzilla.gnome.org/show_bug.cgi?id=408898
> 
> Heh. One of the reasons I dislike bugzilla: it works differently for 
> everybody. The gnome bugzilla looks a lot prettier than the kernel one, 
> but either I'm confused or you are, because you seem to have made all the 
> patches separate bugzilla entries (maybe that's just how gnome patches are 
> supposed to be done? It was nonobvious to actually find the discussion 
> about the patches themselves from the bug you pointed at ;^).

Yeah, its was me being confused :) I didn't look at the patches so I
just assumed you split them out because they where fully independent
(please don't ask me to try to explain how such a stupid assumption came
about :)

> > In regards to Devil's pie I didn't link it as an example of something
> > that did exactly what you wanted, I linked it to show that there where 
> > tools for doing further customizing of components in GNOME.
> 
> Sure. And that's what "control-center" is too.
> 
> I'm a bit confused why it's apparently considered to be a good idea to do 
> something in an add-on program, but not in the standard control center 
> app?
> 
> Yeah, Devil's pie apparently does other things too (ie it waits for window 
> events etc, if I understood it right), but in many ways, for things that 
> are just pure configuration, it seems to be some psychological trick where 
> things that aren't "allowed" by the core people because they are against 
> the HID guidelines can apparently only be broken by external programs? 
> 
> It's like "we know people want to break out guidelines, and we add the 
> config options to allow them to do so, but then because they break the 
> guidelines we don't allow those options to be set by any standard 
> configuration tool".
> 
> It's that a bit dodgy? Wouldn't it be better to just admit that the HID 
> guidelines are just defaults - instead of being in denial about it and 
> saying "they're just defaults, but they are defaults that you have to use 
> some other program to change?"

Ok, so the 'standard' GUI tools of GNOME is what everyone who installs
GNOME sees and gets, so the thinking has been that we should keep the
default preferences and configuration tools without to many items in
order to make navigating them quick and easy as the items which are
there are things which are meant to be critical for people to be able to
adjust. (yes, we/I are aware that what is critical and not is a
subjective thing, but lets call the current options made available with
a GUI by default the rough consensus of what is critical within the
community.)

In regards to having extra applications that lets you control and adjust
things this is not seen as contrary to our policy as any user who
installs such tools/gui's are to be considered advanced/experienced
enough to be able to use his/hers system even if the control center has
5000 items. But at that point it is no longer 'we' who push these extra
options on the users, but something they choose to add themselves. The
problem is and have never been that the GNOME community thinks people
shouldn't be allowed to tweak their UI, instead the idea was that we
keep the 'core' slim and clean and then people who want more control can
install extra tools to get extra configureability. Due to this a lot of
applications and tools in GNOME do support more adjustments than what is
obvious in the normal GUI, and which people can activate either with the
gconf-editor 'registry tool' or with tools such as Devils Pie, gTweakUI
and so on.

> > My feeling was that you where extrapolating from your one missing 
> > feature that GNOME offered no configurable features.
> 
> Sure I was. No question about that. But I'm not exactly extrapolating from 
> a single feature. It was just one _I_ happened to care about, but others 
> care about other features, and looking at the bugzilla discussions, I 
> notice that people there argue about removing *other* config options (ie 
> look at how there's somebody pointing to bugzilla entry 154614: "Consider 
> removing the auto-raise preference from the user interface").
> 
> In other words, in the very same discussion about the one feature _I_ care 
> about, there's another gnome developer who argues that gnome should remove 
> ANOTHER configuration entry that somebody else is bound to care about.
> 
> So I object to you claiming that I'm only extrapolating from "one missing 
> feature". For _me_ it was one missing feature. But that's not what I use 
> to extrapolate from. I use the *fact* that Gnome has in the past removed 
> other features, and is *still* apparently talking about removing yet more 
> config options from view.
> 
> WHY? It's a disease, I tell you. The apparent inability to accept the fact 
> that we're not all a uniform gray paste.
> 
> That very bugzilla entry shows exactly the problem I have. Apparently 
> gnome thinks that "few people" using a feature means that it shouldn't be 
> exposed. Can you say "gray uniform goo, based on some populist message 
> where experts and people who have an opinion are to be shunned and looked 
> down upon"?
> 
> So yes, for *me* it was one feature that simply makes Gnome totally 
> unusable on some of my machines (and since I want uniformity on *my* 
> machines, that measn that it's unusable on them all). But that's not the 
> reason I extended it to "gnome people don't seem to like people who want 
> to do their own thing".

I hear you and I have at times also inwards in the GNOME community tried
to get people to be more clear in communicating that when they talk
about 'removing a feature' it is not in the context of 'removing it', 
but in the context of not exposing it in the default GUI.

I think part of the problem why this has grown to such an issue for
people who don't follow GNOME closely has been that maybe we have failed
in GNOME to package and present the power user tools actually available
in a good way. We should maybe even make it a requirement that when
someone removes something from the default GUI there is a requirement to
add it to an add-on tool in the same go.

I mean your feature was actually missing until your patches now are
being merged, but there are others already in there not exposed and thus
'gone' from the view of many, but I don't think you or anyone else would
have had much of a problem with that if it had been clear that easy to
use tools to adjust and manage these things had been available with a
'apt-get install gnome-power-tools' or something along those lines.
I also don't think that we managed to communicate clearly that good
patches adding features will normally be merged, but that the GUI to
control these new features might end up going into a tool like gTweakUI
instead of into the control center. Instead I feel there has grown an
impression out there that since there is that the hesitation to add more
options to the default gui tools also means that getting the
'infrastructure' code in terms of support for certain features into the
code is also hard.

I would also like to say that, while the public image might give a
different impression, ever since GNOME 2.0 I think the number of GUI
options in GNOME have grown steadily. And while 'removing' some features
from the config has been talked about and even done a few times it is in
reality a very very rare occurrence. The single biggest 'feature
removal' was probably the switch from Sawfish to metacity, but that
change was not done as I saw some people claim on Slashdot done due to
'to many configuration options in Sawfish', but due to Sawfish going
basically unmaintained as the maintainer got a job of Apple. Sawfish
being written in its own Lisp dialect and coming with its own Lisp
interpreter was not something we at the time had a lot of volunteers
(aka anyone) wanting to take over maintenance of so a new window manager
had to be found. Metacity actually become the new window manager due to
most GNOME devs switching to it willingly, so even though its gotten a
lot of criticism over the years for its sparseness of features it
actually got chosen due to wide public adoption combined with being in C
like the rest of GNOME and not as a top-down decision from an
undefinable cabal of community leaders :)

Christian