Re: Menu Proposal
On 2006-11-29 04:19:25 -0800 Christopher Armstrong [EMAIL PROTECTED] wrote: Hi all I wish to make a proposal regarding NSMenu. There has been alot of debate about GNUstep's stacked menus in the past. It is clear that alot of people like GNUstep's stacked menus, but alot of people also have different ideas about how menus should be displayed. I want to propose one pragmatic solution that should make it easier to support multiple menuing paridigms. I have been looking at the code in NSMenu, and at the moment NSMenu is reponsible for creating an NSMenuView and the NSPanel object that it is housed in. As a result, this code makes the assumption that a menu is always in a separate window, and that there is only one displayed representation of a menu. It also assumes that the menu representation is drawn in the same process with an NSMenuView object. In order to support different paridigms, such as the (addmittedly broken but popular) one-menu-per-main-window on Win32/Gtk/Qt or Etoile's menu server, I believe that programmers currently need to modify NSMenu through means such as subclassing or overriding using categories. These methods are prone to breakage as they often depend on internal implementations. I am proposing that we separate the visual representation of a menu (which includes the window it is drawn in (NSMenuPanel), the view (NSMenuView) and the item cells (NSMenuItemCell)) from the abstract representation of a menu (NSMenu). I am suggesting we do this allowing people to supply an object which will receive menu update notifications (such as items being added, removed, etc.) and be responsible for coordinating the drawing of the menus and handling events. It should be different from the current use of the NSMenuRepresentation which assumes that the menu representation is a subclass of NSView. This object should implement some sort of protocol for communication between itself and NSMenu, the protocol supplying methods which inform the object of changes in the NSMenu, something like the interaction between a Model and Controller in MVC. For example, you may wish to place a menu on each of your document windows, but this breaks the current assumption that there is only one visual representation (view) of the menu. In this case, the intermediary object would sit between NSMenu and the associated set of NSMenuViews which reside in each document window. It would be responsible for receiving update messages from the NSMenu object and forwarding them to each of the NSMenuViews. These views in turn would somehow notify the NSMenu when they are clicked/selected. I think this may be a reasonably opportune time to play with the current design, as Apple have deprecated the usage of NSMenuView and NSMenuItemCell along with the -menuRepresentation property of NSMenu (according to the Cocoa docs). Before I possibly attempted to implement such a solution, I wanted to discuss it with the list as I fear this solution may be too complex where simpler solutions exist, and I know it has implications for some other areas in the AppKit (especially popup buttons). I don't wish to engage anyone in debate about the merits or disadvantages of stacked vs horizontal menus; I think this has been discussed enough on these mailing lists before. I believe we should be pragmatic and offer people a choice. It would be helpful to gain some feedback about this idea, particularly its feasibility. I think it is not too difficult to implement and I do think it is necessary if we want to be flexible in supporting different kinds of menu paridigms. Cheers Chris another thing to consider is context sensitive menus, which regardless of main menu implementation want a vertical menu i for one would like to see NSPopUpButtons cleaned up, as it is theres NSPopUpButton has a NSPopUpButtonCell has a NSMenu has a NSMenuView has a NSMenuPanel, there seems to be more code for pop-up buttons in the NSMenu* classes than NSPopUpButton* (seems like it'd be cleaner to have just a window with a matrix in NSPopUpButtonCell).. also it seems like this class has been updated sequentially to conform to apples NSMenu implementation of the day and its sort of a hodge podge of characteristics from all the different NSMenu implementations so i'm basically indifferent twords support of different menu paridigms, i definately think NSMenu* needs an audit ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Menu Proposal
Matt Rice schrieb: On 2006-11-29 04:19:25 -0800 Christopher Armstrong [EMAIL PROTECTED] wrote: Hi all I wish to make a proposal regarding NSMenu. There has been alot of debate about GNUstep's stacked menus in the past. It is clear that alot of people like GNUstep's stacked menus, but alot of people also have different ideas about how menus should be displayed. I want to propose one pragmatic solution that should make it easier to support multiple menuing paridigms. I have been looking at the code in NSMenu, and at the moment NSMenu is reponsible for creating an NSMenuView and the NSPanel object that it is housed in. As a result, this code makes the assumption that a menu is always in a separate window, and that there is only one displayed representation of a menu. It also assumes that the menu representation is drawn in the same process with an NSMenuView object. In order to support different paridigms, such as the (addmittedly broken but popular) one-menu-per-main-window on Win32/Gtk/Qt or Etoile's menu server, I believe that programmers currently need to modify NSMenu through means such as subclassing or overriding using categories. These methods are prone to breakage as they often depend on internal implementations. I am proposing that we separate the visual representation of a menu (which includes the window it is drawn in (NSMenuPanel), the view (NSMenuView) and the item cells (NSMenuItemCell)) from the abstract representation of a menu (NSMenu). I am suggesting we do this allowing people to supply an object which will receive menu update notifications (such as items being added, removed, etc.) and be responsible for coordinating the drawing of the menus and handling events. It should be different from the current use of the NSMenuRepresentation which assumes that the menu representation is a subclass of NSView. This object should implement some sort of protocol for communication between itself and NSMenu, the protocol supplying methods which inform the object of changes in the NSMenu, something like the interaction between a Model and Controller in MVC. For example, you may wish to place a menu on each of your document windows, but this breaks the current assumption that there is only one visual representation (view) of the menu. In this case, the intermediary object would sit between NSMenu and the associated set of NSMenuViews which reside in each document window. It would be responsible for receiving update messages from the NSMenu object and forwarding them to each of the NSMenuViews. These views in turn would somehow notify the NSMenu when they are clicked/selected. I think this may be a reasonably opportune time to play with the current design, as Apple have deprecated the usage of NSMenuView and NSMenuItemCell along with the -menuRepresentation property of NSMenu (according to the Cocoa docs). Before I possibly attempted to implement such a solution, I wanted to discuss it with the list as I fear this solution may be too complex where simpler solutions exist, and I know it has implications for some other areas in the AppKit (especially popup buttons). I don't wish to engage anyone in debate about the merits or disadvantages of stacked vs horizontal menus; I think this has been discussed enough on these mailing lists before. I believe we should be pragmatic and offer people a choice. It would be helpful to gain some feedback about this idea, particularly its feasibility. I think it is not too difficult to implement and I do think it is necessary if we want to be flexible in supporting different kinds of menu paridigms. Cheers Chris another thing to consider is context sensitive menus, which regardless of main menu implementation want a vertical menu i for one would like to see NSPopUpButtons cleaned up, as it is theres NSPopUpButton has a NSPopUpButtonCell has a NSMenu has a NSMenuView has a NSMenuPanel, there seems to be more code for pop-up buttons in the NSMenu* classes than NSPopUpButton* (seems like it'd be cleaner to have just a window with a matrix in NSPopUpButtonCell).. also it seems like this class has been updated sequentially to conform to apples NSMenu implementation of the day and its sort of a hodge podge of characteristics from all the different NSMenu implementations so i'm basically indifferent twords support of different menu paridigms, i definately think NSMenu* needs an audit I like the original idea, although I currently don't see to much benefit from it. Perhaps we should have the interface for the new implementation first, before we get any new code. As for the second mail on NSPopUpButton I totally seem to miss the point here. What is the problem here? I have been involved in the development of NSPopUpButtonCell, so I may be blind to the fact that the code here is hodge podge. Cheers, Fred ___ Gnustep-dev mailing list
Re: Menu Proposal
Richard Frith-Macdonald wrote: On 29 Nov 2006, at 12:19, Christopher Armstrong wrote: I have been looking at the code in NSMenu, and at the moment NSMenu is reponsible for creating an NSMenuView and the NSPanel object that it is housed in. As a result, this code makes the assumption that a menu is always in a separate window, and that there is only one displayed representation of a menu. It also assumes that the menu representation is drawn in the same process with an NSMenuView object. 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. In order to support different paridigms, such as the (addmittedly broken but popular) one-menu-per-main-window on Win32/Gtk/Qt or Etoile's menu server, I believe that programmers currently need to modify NSMenu through means such as subclassing or overriding using categories. These methods are prone to breakage as they often depend on internal implementations. I am proposing that we separate the visual representation of a menu (which includes the window it is drawn in (NSMenuPanel), the view (NSMenuView) and the item cells (NSMenuItemCell)) from the abstract representation of a menu (NSMenu). I am suggesting we do this allowing people to supply an object which will receive menu update notifications (such as items being added, removed, etc.) and be responsible for coordinating the drawing of the menus and handling events. It should be different from the current use of the NSMenuRepresentation which assumes that the menu representation is a subclass of NSView. This object should implement some sort of protocol for communication between itself and NSMenu, the protocol supplying methods which inform the object of changes in the NSMenu, something like the interaction between a Model and Controller in MVC. I think the current separation, using notifications, is a pretty good start and could be extended if necessary ... but I'm not sure that it *is* necessary to go much further ... the assumption that the menu representation is a subclass of NSView appears to be OK for doing per-window menus, and in the etoile case of having a completely separate process handling the menu, it seems to me that the best solution is to replace the entire NSMenu with a proxy to that remote process. I agree, although -menuRepresentation makes the assumption that there is one and only one representation of a menu i.e. there can't be many menu views. Whilst the multiple menu views idea involves multiple instantiations of NSMenuView, practically they should all be displaying exactly the same thing, just with consideration for the window they are displayed in. For example, you may wish to place a menu on each of your document windows, but this breaks the current assumption that there is only one visual representation (view) of the menu. 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. In this case, the intermediary object would sit between NSMenu and the associated set of NSMenuViews which reside in each document window. It would be responsible for receiving update messages from the NSMenu object and forwarding them to each of the NSMenuViews. These views in turn would somehow notify the NSMenu when they are clicked/selected. Alternatively, the menu can send a notification, and all views associated with it could watch for that notification and handle it. The notification mechanism is already used to inform menu representations of changes to the items in a menu, and implicitly has the feature that multiple views can observe the same notification. The notification center is acting as the intermediary object you suggest. The use of notifications has the additional advantage that it allows other objects outside the menu/representation mechanism to track the operation of menus. For having a menu in the current process with a representation in a separate process
Re: Menu Proposal
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
