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.
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev