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

[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. It's a
symptom of brain damage, not a feature of note.  And worse, they're
configurable -- so you can't rely on muscle memory to find the button,
because somebody else might have moved it or you might not be on your
computer. 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?

Getting right down to it: Apple needs toolbars because they broke their
menus and eliminated the normal "right-press menu" 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."

-- 
| 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/