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

[Lars Sonchocky-Helldorf]

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.

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!

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

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

Uhmm, we talk here about Unix don't we? Everybody has its own login and 
settings. If you forget to logout and somebody changes your settings 
that your fault. And if you are not on your computer you either have 
netboot which allows you to have your environment across the whole 
company or whatever or the computer is configured that differently that 
"muscle memory won't help you either.

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

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


conclusion:

I like to have the option (via toggle button) to have a toolbar on the 
top of my windows. It gives me an idea what I can do within that window 
at a glance. Desktop space  is no issue because even here on my 1024x768 
powerbook it is spacy enough (who has a computer with a smaller screen 
nowadays?).

having options is "a good thing (tm)"

greetings, Lars

> --
> | 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/
>
>
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> http://mail.gnu.org/mailman/listinfo/discuss-gnustep