It's easy to make everyone happy with stuff like NSToolBar. We put an
implementation in gnustep-gui. If you are an OpenStep purist and don't
want to use it, you don't use it - you can ignore it. If you are an
Apple-compatible guy and want to use it, you use it. I don't see why
we
should remove NSToolBar from gnustep-gui. The problem arises when
adding
Apple compatibility pollutes or confuses the original OpenStep classes
(then, we need a "superior workaround"). Adding an additional separate
class does not.
I know at least one core developer who will likely fight the inclusion
of NSToolbar. Many think Apple's Toolbar implementation sucks.
In my experience, things tend not to work very well when we are "fighting"
between each other. :-)
Both points of view have their reasons.
In this case to me it looks like if we add NSToolbar and write clearly in
the documentation that it's there just/mainly for compatibility with the
current Apple system (maybe we document it in a different section, outside
the main listing of classes, in an Apple compatibility area), the solution
should make everyone happy and I don't see any reason to "fight".
The mission statement of GNUstep.org indicates things that are sane
Cocoa additions to the OpenStep spec will be included in GNUstep (the
API).