Re: Subclassing NSToolBar.
Re: Subclassing NSToolBar.
- Subject: Re: Subclassing NSToolBar.
- From: Ali Ozer <email@hidden>
- Date: Fri, 5 Oct 2001 10:18:50 -0700
>
Ideally, the class should be flexible enough that it can be extended
>
rather than re-implemented, but if so many clients need to "roll their
>
own", it would be very helpful (in terms of implementation details and
>
providing a consistent user experience) if we could duplicate the
>
pieces that are the same as the base (for instance, the customization
>
dialog, sliding and dragging behavior, and so forth.)
A primary purpose of NSToolbar is to allow developers to provide the HI
spec for a toolbar in their apps. In doing this it does provide
extensibility in many areas (you can provide your own views, for
instance); but in others it doesn't, partly on purpose, and partly
because of priority/time issues.
As far as being able to reuse toolbar behaviors such as icon dragging...
These behaviors are not a primary external feature of NSToolbar, so
NSToolbar's APIs aren't well-suited for subclassing in order to make use
of such features. (And, consider that in a future release, the process
of customizing a toolbar might totally change, and there might be no
icon dragging, for instance.) It would be nice to make these services
available as generic APIs, but again, not everything is possible. Source
code could be useful, but there are issues with that (which have been
discussed before).
>
I for one would love to see Apple release the code to NSToolbar as
>
sample code (just as they have the source to TextEdit.app) because even
>
though NSToolbar is quite useful, it appears that *many* applications
>
(I believe OmniWeb, System Preferences, probably Mail from your
>
description, and perhaps more) roll their own toolbar.
Actually many clients do use NSToolbar. Omni had their own, and I'm
pretty sure they switched; Mail, PB, and IB use NSToolbar pretty much
as-is. I have also seen toolbars appearing on many third party apps.
Ali