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