Re: Toolbars (Was: Re: Unimplemented AppKit classes)

[Jeff Teunissen]

Lars Sonchocky-Helldorf wrote:
> 
> Am Donnerstag den, 23. Januar 2003, um 09:53, schrieb Jeff Teunissen:
> 
> > Stefan Urbanek wrote:
> >
> >> On 2003-01-22 19:28:08 +0100 Tobias <ibotty@web.de> wrote:
> >>
> >> (snipped)
> >>
> >>>> For an application where a Mac or Windows developer would use a
> >>>> toolbar, a NeXT developer would use one or more floating panels for
> >>>> most efficient use of screen space. That's why panels order our when
> >>>> their app becomes inactive -- to avoid unnecessary clutter. The NeXT
> >>>> GUI is designed to use a big screen efficiently: the bigger the
> >>>> screen, the more useful it is.
> >>> i got your point. i didn't thought about it.
> >>> but we could nevertheless implement this api... better than apple did.
> >>> as pointed before, we could offer a way to and let the user decide,
> >>> whether he wants these toolbars as seperate floating panels
> >>
> >> I like the idea of floating panels. This can save screen space if we
> >> had
> >> only single toolbar panel/window for the whole application. The toolbar
> >> should be 'window sensitive' and should change its contents depending
> >> on
> >> the key window. Another option for the toolbar should be, if it shuold
> >> be visible or not when application is hidden. IMHO, implementation of
> >> such toolbar-panel should be easier than implementing toolbars that are
> >> part of a window.
> >
> > It is easier -- you make a panel, set some settings, and add some
> > stateful
> > buttons. Voila, you have a palette.
> >
> > On the other hand, an Office-style "Toolbar" (which is pretty-much
> > exactly what NSToolbar implements) is one of those things that is
> > added to a program to cover up for a number of fundamental
> > stupidities.
> 
> No, it's per window (and so per context: the browser window in for
> instance chimera has a different toolbar than its download window) and
> not one toolbar for one application.

I was differentiating a palette (a useful UI control in certain contexts)
from a toolbar (a band-aid to hide user-interface warts).

The toolbar became popular because people couldn't effectively use
Microsoft Word's menu system (because it was far too complicated) and
needed something usable. Instead of cleaning up the app and making it more
usable, they added buttons for you to memorize (the same way they
previously had menus you had to memorize, because very little was where it
"should" be).

Nobody (except Apple) even considered that toolbars were the solution to a
problem that didn't exist, and had never existed.

As for Chimera...My God...a toolbar on a *download* window? It makes zero
sense.

> If it would be one toolbar per application I would opt for an palette
> too, but if this palette has to change depending which window is
> frontmost I would not like this solution. How would one know for which
> window the palette is currently acting? A changing palette, that is
> confusing!

Of course it's confusing. That's why I didn't suggest it.

> > It's a symptom of brain damage, not a feature of note.  And worse,
> > they're configurable --
> 
> That's a good thing! You keep only the commands/actions you actually
> need and you can place them in that order you prefer.

How is it a good thing to have an app with such a poor interface that you
can't use it effectively without changing it? If there is a need for a
toolbar -- if one even makes the app more useful -- then the app needs to
be fixed.

Brain damage.

[snip]

> > You have to recognize the functions on the toolbar by image, not
> > location. Apple had these same arguments when it wasn't their
> > implementation being argued about...the wheel turns, does it not?
> 
> No you have the option to view an Icon (big or small), a Text or both. I
> use usually the only text option, but that is only because I don't like
> the Icons of some apps (including Finder).
> 
> You can also hide the toolbar if you don't like it at all (oval button
> on the right side of the window title toggles this)
> 
> > Getting right down to it: Apple needs toolbars because they broke
> > their menus and eliminated the normal "right-press menu"
> 
> most apps I know of also feature a context sensitive menu which you get
> by ctrl-click or you just use your right mouse button for this (if you
> got any two buttons USB mouse, most of them work out of the box)

I'm not talking about a context-sensitive menu. I'm talking about the
spring-loaded "right-press menu" that was on NeXT (and which GNUstep has a
very-slightly-broken-by-necessity version of, because GNUstep can't just
steal right-click from all X apps). If you pressed the right mouse button
(anywhere on the screen, not just inside the app's window), a duplicate of
the app's main menu appears with its title centered on the mouse pointer's
hot spot. This makes it very easy to get at all of the app's functionality
in a very short time, with minimal fuss and no high-speed precision
mousing. In fact, some people prefer to hide the regular menus and only
use the spring-loaded versions.

Context-sensitive menus are often nice too, because they limit what they
show to what is immediately possible given what was clicked...but the way
NeXT did it made toolbars obsolete before they were even invented.

> > that makes toolbars a completely superfluous distraction. In this
> > manner, the app menu is like a complete toolbox that is always
> > directly beneath the mouse pointer -- so it doesn't need the precision
> > mousing necessary to reach a button that's way off in some random part
> > of the window (or outside it). And what's more, commonly-used menu
> > entries have command-key alternatives, and you can add your own
> > keyboard alternatives for commands (although I don't see any way to
> > specify that an alternative is triggered with the Alternate key
> > instead of, or combined with, the Command key at this time).
> >
> > "We can't be bothered to actually work on our menu system or to make
> > our program operate intelligently, so we'll force you to design your
> > own button-based interface."
> 
> calm down.

I am calm (this discussion isn't even threatening to get me riled).

The above quote is accurate.

Toolbars do not simplify anything -- they're an additional complication
that gets in the way of getting useful work done.

[snip]

> having options is "a good thing (tm)"

Having good options is a Good Thing. Toolbars are not good options.

-- 
| Jeff Teunissen  -=-  Pres., Dusk To Dawn Computing  -=-  deek @ d2dc.net
| GPG: 1024D/9840105A   7102 808A 7733 C2F3 097B  161B 9222 DAB8 9840 105A
| Core developer, The QuakeForge Project        http://www.quakeforge.net/
| Specializing in Debian GNU/Linux              http://www.d2dc.net/~deek/