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."