Re: Menu Proposal

[Richard Frith-Macdonald]

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.