Re: Unimplemented AppKit classes

[Jeff Teunissen]

Tobias wrote:

> > From another (*n*x/*step) point of view, though, these classes are
> > superfluous and can even be harmful.
> >
> > Covering NSToolBar: It's a user-customizable toolbar like you see in
> > innumerable Mac and Windows applications. Easy to write, to be sure.
> > Makes perfect sense in those contexts, also. And yet, that's code that
> > is bulking up an already-large library and being a (potential) source
> > of bugs, all for something that doesn't even make sense in software
> > built on *nix principles.
> 
> toolbars dont make sense in unix/next applications?

No, they don't. Not in a NeXT-style GUI -- one of perhaps three (and
neither GNOME nor KDE are on that short list) GUI environments built on
*nix principles.

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.

What are the other two? NeWS and (to a much lesser extent) OpenWindows
(which eventually became Open Look).

> huh?
> you dont like the toolbar in mail.app, projectbuilder.app... and most
> other NeXT-apps you dont have to, but there was a toolbar even in good
> old next apps.

No, there wasn't. ProjectBuilder did not have a toolbar -- it had a small
group of icons as part of its interface. This is not the same thing as a
toolbar, though it is similar in function to one. Mail can be argued to
have a toolbar after a fashion, and that is one of Mail's worse
misfeatures. But then, Mail was/is a truly old program (14 years, now -
Mail was already 3 years old in 1991!), so they can be excused for it.

[snip]

> we are gnusteppers, thus we may find a better solution.

The better solution is good UI design.

[snip]

> >                    *step applications aren't supposed to have modes
> > that need status information displayed, because they're supposed to
> > follow the KISS ("Keep It Simple, Stupid!") principle.
> 
> nsstatusbars are not only for status messages.
> the name is a bit misleading.

[snip]

It's not misleading at all. That's what status items are for -- to show
application or system-service status, or to provide interactivity when
another program is being run. That they can be (ab)used to do other things
is not Apple's problem.

> it is not practical in gnustep/X, the way apple designed it,
> but we could find a nice workaround, e.g.: by employing cards.

We don't need a workaround. Even on OS X, status bars may not be available
and so no app should depend on them. It's right there in the docs.

In point of fact, status items are usually obviated by the presence of a
NeXT-style menu system. Applications and system services can provide
Services-menu items and submenus dynamically.

[snip]

> > Extensions are *great*, but only if they're good ones. GNUstep ought
> > to be even more NeXT-like than NeXT was, IMO.
> i am more equal than you!

By this, I mean that there are areas where NeXT didn't go far enough.
Window Maker's Clip, or the Fiend, are an excellent example of a real
deficiency in NeXT's system. We can fix these, to be "more NeXT-like than
NeXT".

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