gnustep-dev
[Top][All Lists]
Advanced
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Menu Proposal

From: Matt Rice
Subject: Re: Menu Proposal
Date: Thu, 30 Nov 2006 14:44:58 -0800
User-agent: GNUMail (Version 1.2.0) 
On 2006-11-29 16:32:48 -0800 Fred Kiefer <address@hidden> wrote:


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
well i should apologize, for derailing this thread but menu/pop-up cohesion really gets my goat and it probably has more to do with apples design (and inability to stick with one) than GNUstep's implementation...
my main issue with it is the usage of _ownedByPopUp in NSMenuView/NSMenuItemCell, i'm all for code reuse, but when it starts changing behaviours based on private settings and what not, 
it just complicates the both normal NSMenu's and the PopUp's menus
there really aren't a whole lot of special cases yet but its only able to get more complicated
when we add support for icon pull downs which is soemthing like a little square button with a down arrow, that clicking causes a pull down selection deal to appear under the button, the first item in the menu isn't even shown in the menu, because it is the pop-up title, and not a selectable menu item.. which will require another extension -owningPopUp and more special case code based on specific settings inside of the pop-up button
if NSMenu* had set/get methods and ivars for configuring all the different variations of how a menu can be affected that'd be a little better but, we can't really change it too much because of NSPopUpButton's -setMenu: so we can't exactly subclass NSMenu* to implement the pop-up behaviours,
now if i were to propose we add NSMenu -setCompletelyIgnoresMenuItem: for the above case of pull downs 
i'd expect a response similar to 'get out of here!'
but the current behaviour where pull downs just draw the first item directly above the pop-up doesn't work because its a little square button, not the same size as the pop-up
if there really was a good argument for all this complication/quasi code reuse that'd be ok, but there really isn't besides what a 4th way to add items? NSPopUpButton* would be a little bit larger, but many times simpler without it..
reply via email to
[Prev in Thread] Current Thread [Next in Thread]