On 30 Nov 2006, at 05:17, Christopher Armstrong wrote:
Richard Frith-Macdonald wrote:
I have been assuming that we could support per-window menus by
dynamically moving the menu view from window to window as the menu
in each window needs to be drawn (since this is what is already
done for transient menus), but having multiple menu views may be
better.
In terms of the event handling system, how would such a mechanism
work? There still needs to be a "view" in each window of some sort,
so are you proposing some sort of "dummy" view in each window where
the real NSMenuView is ripped out each time an update is triggered
and temporarily pasted into the window. I don't think I understand
what you mean.
Not really proposing that (though obviously some placeholder view
class would be needed which would replace itsself with the menu
representation when necessary) ... hopefully it's clear below that I
think multiple menu representation views are *probably* the best
approach, but that other options are possible and should be examined.
Not necessarily ... the current implementation already uses the
same view in two different windows (for transient menu
support) ... but it's probably better to have multiple views (in
the current implementation the rectangle the view is drawn in is
the same in both windows, but that would not generally be the
case). I would suggest carefully examining the option of
extending the single-view-moved-between windows approach before
deciding that multiple views are really necessary/best.
What was your ideas as to how a single view is moved between
windows. I can't picture how this would work.
I forget how it's done in NSMenu ... probably just calls -addSubview:
to place the menu view inside the content view of the window.
In general, the controlling code would need to call -addSubview: and
then -setFrame: to resize the subview to fit a new rectangle, and the
window representation view would need to override -setFrame: to
recalculate layout according to the window and frame it is in.
This could be controlled by the windows decoration view ... ie when
the decoration view is told to redraw any part of itsself, it draws
window decorations and when it gets to the point where it wants to
draw the menu, it adds the menu view from the main menu and asks it
to draw itsself, then it puts the menu view back in the main menu.
However, having multiple menu views, each permanently in a separate
window, may be a cleaner/simpler solution. I haven't done much work
on menus for a long time, so i don't currently have a good enough
grasp of the menu code to know what the detailed technical advantages/
disadvantages of the two approaches are. Conceptually, multiple
views seems clearer, but I guess there must have been a reason for
the current implementation using a single view shared between two
windows.
Reading this email gave me a different idea. Instead of trying to
develop a protocol for an intermediary layer, perhaps we could
extend allow NSMenuView to associate a NSMenu with it, without
actually causing the NSMenu to "own" it. In addition, NSMenu should
allow the option of turning off its display of an NSMenuPanel with
the NSMenuView in it. The "extra" NSMenuViews should probably rely
on NSMenu notifications so they can update themselves. We could
probably rely on NSMenu to continue handling transient menus in
this instance as well.
That sounds good to me.
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev