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 -- Christopher Armstrong carmstrong ^^AT^ fastmail dOT com /Dot/ au _______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
