Re: Question on NSToolbar

[Fred Kiefer]

Quentin Mathé wrote:
> Le 30 déc. 08 à 20:07, Fred Kiefer a écrit :
>> For this I need to understand a bit more of the current toolbar code and
>> what better way is there to do this than to rewrite that code?
> 
> In NSWindow+Toolbar.m, only -runToolbarCustomizationPalette:,
> -toggleToolbarShown:, -toolbar and -setToolbar: have to be kept almost
> as is, they could also be moved back into NSWindow.m. The other

Oops, now I started my changes by rewriting these methods :-)
I moved the toolbar into the NSWindow as an ivar, which makes some of
the operations here much easier. When you started to write this code
here, you didn't want to touch the NSWindow class itself, but now things
are different. have a look at my code it already is in SVN.

> NSWindow+Toolbar methods have to be entirely rewritten to insert the
> toolbar view (GSToolbarView) below the title bar view inside the window
> decoration view. This behavior could be handled by -_toggleToolbarview,
> but the current code of this method won't help, so it must be discarded.
> For -_adjustToolbarview, the code won't be useful too, so you can either
> remove it or try to use it for computing the geometry of the window
> decoration subviews when a toolbar view is present in addition to the
> title bar view.

This will be one of the next steps after the merging of NSToolbar and
GSToolbar.

>> Now I stumbled over the split between NSToolbar and GSToolbar. Why is
>> this needed or is it needed at all?
> 
> I think GSToolbar should probably be removed. I initially wrote this
> superclass to disallow the use of some methods such as -setSizeMode:
> when the toolbar isn't bound to the window with -[NSWIndow setToolbar:].
> When the toolbar is only bound to a GSToolbarView with an arbitrary
> location inside the window, -setSizeMode: and -setDisplayMode: don't
> make much sense to use because you cannot know how to position the
> toolbar view when it gets resized or it will simply break the UI layout
> with the other views around.
> The ability to create a toolbar not owned by a window and freely
> positionned could be kept even if GSToolbar is merged into NSToolbar
> though. I'm not sure it's worth to do or to expose in the public API,
> When I wrote this code I thought this would make easy to create a
> toolbar such as the one in iPhoto located at the bottom of the photo view.
> 
Most likely the toolbar view should just notify its containing view of
the needed size change and rely on changes by that view. I need to
rethink this approach...

>> In the long run I would like to remove the window ivar on NSToolbar and
>> with that in place there surely is no reason for this separate super
>> class, but even now I cannot find any use of it in the GNUstep code
>> (apart from the ToolbarExample that Quentin pointed to), does it get
>> used outside?
> 
> No it isn't, I don't think anybody has ever used this feature.

Great, then I will start to do the merge.