gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Question on NSToolbar


From: Quentin Mathé
Subject: Re: Question on NSToolbar
Date: Fri, 2 Jan 2009 18:33:35 +0100

Le 1 janv. 09 à 20:48, Fred Kiefer a écrit :

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.

Yes.

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.

Putting the ivar in NSWindow looks definitely better given the toolbar API. I read the recent commits you did, your changes look great :-) I wrote this code at a time where I was still learning ObjC, so there are probably various things to improve or fix.

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

Yes, something along these lines seems good.

Btw, basic support for toolbar customization is available in the Toolbar branch. I'm just mentionning it in case you want to reuse it later on.
See http://svn.gna.org/viewcvs/gnustep/libs/gui/branches/Toolbar/
This branch includes various changes to existing toolbar related files and some new files such as GSFlow and GSToolbarCustomizationPalette. GSFlow provides the possibility to layout subviews in a flow style, as Mac OS X does for the toolbar items presented in the toolbar customization palette.

Quentin.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]