Re: NSToolbar (was Re: Portability/Compatability between GNUstep<---> Cocoa...)

[Alexander Malmberg]

Jason Clouse wrote:
> There are probably some good arguments that toolbars are not good UI
> design,

Perhaps, but I don't think so, and that isn't what I worry about.

> or that they aren't implemented well.

Well, their implementation is their problem; a poor implementation on
their part doesn't hurt us _if_ we can implement it well.

The problem with NSToolbar (and, in general, other bad changes)
ultimately lies in the
interface (ie. the API, not the UI). It can't be well implemented.

> But nobody is forcing those folks to use it;
> and it doesn't do damage to implement them.

As developers of GNUstep, we _are_ forced to take it into account,
regardless of whether we use it or not. (And note that this is free
software; most of us are both developers of and users
of GNUstep, at least to some extent.)

New code bloats the library, adds new complexity to the code, and
hampers the development of better alternatives. The first two directly
makes life harder for those working on GNUstep, and indirectly makes
things worse for developers using GNUstep. The last one directly hurts
developers using GNUstep since they get stuck with an inferior
interface, and hurts morale of developers of GNUstep.

To elaborate a tiny bit:
(lots could be said about this :) 

1. Bloat.

All new code(/interfaces) bloats the library. The code needs to provide
some benefit (the mission page talks about 'substantial value') that
outweighs its bloat, or it shouldn't be added. It also needs to be
appropriate for the library it's being added to.

Apple's scripting classes fail horribly here. IMHO, XML fails the
appropriateness part for -base. NSXMLParser also fails the 'benefit vs.
bloat' part (the bloat introduced by an XML parser isn't worthwhile if
the interface to the parser is crippled). NSToolbar is ok wrt this.

(Note that this is _source_ bloat. A compile time switch doesn't help
here since it doesn't reduce the size of the source.)


2. Complexity.

Complexity is Bad. (If I really need to explain why, I can, but it
should be clear. :) Design is mostly about minimizing complexity; tons
of stuff has been written about this already.

Anyway, new code adds complexity; how much depends on the code. An
isolated new class that uses only public interfaces of other classes
likely adds little complexity, while a new class that interacts heavily
with other classes likely adds more complexity.

This is where NSToolbar fails. Instead of using the existing
interactions between NSWindow:s and NSView:s for displaying stuff in a
window, it adds a new "magic" means of adding things to windows, thus
complicating NSWindow, its interactions with views, and its public
interface. This complexity is inherent in the interface; no (compatible)
implementation can get around this. Also, this complexity is
unnecessary; the mechanism for displaying something in a window already
exists, and should have been used (ie. NSToolbar should have been just
another view).

(Again, this is source complexity; a compile time switch won't help.)


3. Better alternatives.

By adding "less-than-perfect" stuff now, we hamper the development of
better stuff (either as part of the library, or as independent
libraries). By adding NSToolbar, we make it harder to get a better
designed GSToolbar done.


Finally:

Uli Kusterer wrote:
> What I'd personally like to see in *any* OS is the concept of "dockable" 
> windows, which could be extended to allow for toolbars as well.

This makes a good example. A toolbar that is just another view could
easily be handled in a "dockable window" scheme; all that scheme has to
support is the documented interface between NSWindow and NSView.
However, if there's an NSToolbar with a different, undocumented
mechanism for adding itself to a window, "dockable windows" will either
not work with such toolbars, or they will have to include considerable
complexity (and depend on this undocumented mechanism) to deal with them
in addition to normal views.


On a general note, if you think "dockable windows" are worth a generic
implementation, I encourage you to implement it so that the rest of us
can test it. :)  (In a separate library until the design's known to work
("plan to throw one away"); when that's done, it may or may not be
something that is suitable for -gui.)

- Alexander Malmberg