gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Menu Proposal


From: Fred Kiefer
Subject: Re: Menu Proposal
Date: Thu, 30 Nov 2006 01:32:48 +0100
User-agent: Thunderbird 1.5.0.8 (X11/20060911)

Matt Rice schrieb:
> On 2006-11-29 04:19:25 -0800 Christopher Armstrong
> <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]