[Usability] Re: [Desktop_architects] Printing dialog and GNOME



Hi,

Tangent fest ;-)

On 12/12/05, Linus Torvalds <torvalds osdl org> wrote:
> The reason I don't use Gnome: every single other window manager I know of
> is very powerfully extensible, where you can switch actions to different
> mouse buttons. Guess which one is not, because it might confuse the poor
> users? Here's a hint: it's not the small and fast one.

Just for the record, since I made this decision I can tell you that
"might confuse people" was not the reason. More evidence for my point
that "might confuse people" is the reason made up by others, not the
reason given by the decision makers.

First some context. The overall metacity plan was to first get all the
defaults right as priority one, and then add more configurability and
options consistent with keeping the defaults right. This was the
driving "principle" if there was a principle at all. (The weekend I
started on metacity the motivation was more "my # %$ WM doesn't work,
I'm just going to write one that works how I like")

On the specific feature of arbitrary button bindings, the full
discussion is archived in bugzilla. But my memory of this feature is:
 - I put in a lot of special cases to get the default behavior exactly right;
   the event handlers for mouse buttons do not look like "run the
action associated with
   this button," they are more complicated
 - I spent a few days trying to code a patch that made button actions
configurable
   while preserving all the detailed behaviors I had coded, and I just
kind of gave
   up because the patch was too hard/complicated/big and I wasn't willing to
   break the default behavior in order to simplify the code.
 - I did put in configuration of the most common stuff people wanted to change,
   like double click action and alt+click modifier key, and this made
most people
   happy (based on reduction in bugzilla/email traffic)

My patch is still in bugzilla, if anyone wants to start from it and
find the simple and elegant way to code it. The patch as I left it is
buggy though and had a couple "hard to fix" problems. Plus it's
against a pretty old version of metacity I guess.

BTW, though I confess that I like to reject window manager patches, I
also spent a ton of time getting EWMH usable and supporting it in
GNOME. The only purpose of EWMH is to make the window manager
replaceable.

You may be noticing that I like the idea of "choice of two
well-focused designs" better than "single choice of one
nobody-hates-it design."

Anyway. The primary issue with preferences in metacity was never
confusing users - that would only be an issue with displaying prefs in
the dialog, i.e. unlimited prefs would be OK, as long as they were
hidden. The more important issue I always had in my mind was the
quality of the defaults, and ability to spend time polishing the
defaults. The tradeoff came from amount of personal time I had, code
complexity, and interdependencies among prefs.

But, I pretty often flamed people complaining about lack of prefs in
bugzilla, so I can't really whine about being misunderstood :-P

> Same with the file dialog. Apparently it's too "confusing" to let users
> just type the filename. So gnome forces you to do the icon selection
> thing, never mind that it's a million times slower.

I don't think "too confusing" was the reason here either, though I
can't speak authoritatively since I didn't design this.

There was also a bad rap here since in the original design spec (and
current file selector) you can in fact just type the filename. The
text entry box appears as soon as you press a key. You can also press
Ctrl+L to get a text box with autocomplete. But version 1.0 didn't
have this since the coders ran out of time.

I'd also point out that OS X makes the same basic decision as GNOME to
avoid the "foo/bar" path notation in the default UI, so while it
(agreed) is not ideal for users who are primarily shell users, I don't
think it's a particularly radical or unprecedented choice in the big
picture.

Havoc



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]