[APBeta] Windows menus

[Paul Rodman]

On Oct 30, 2009, at 6:39 PM, CER wrote:

> I too would say that 'C' is more traditional in Windows land
>
> Problem is... I've kind of gotten used to the way you have it! I may  
> actually need to "see" it implimented to be sure "C" is preferable.

I'm used to the Mac world where there is only one menubar and it  
traditionally has all the menus and items for all windows in the app  
and just disables those that aren't applicable. This makes it easy for  
"muscle memory" since the items are always in the same place. The  
Windows world is different and very alien to me. Menus are not  
consistent and are attached to windows that can have different  
positions, etc.

I have (effectively) implemented (b) since it's easy to do. (c) is a  
lot harder (i.e. a big schlepp). I might leave it as (b) for now and  
see if I can devise a means to do (c) without breaking stuff.

I was hoping to get a release out today, but it won't make it until  
tomorrow at the earliest.

Paul R.

> Paul Rodman wrote:
>> Windows-using folks,
>> What's the desired functionality for the menus in a window?
>>
>> a. Every window has all the menus with all menu entries, and just
>> disables those that don't apply to the window (this is the current
>> method).
>>
>> b. A window only has those menus that contain entries pertinent to  
>> the
>> window, but those menus contain all the items, with the unused ones
>> dimmed.
>>
>> c. A window only has those menus that contain entries pertinent to  
>> the
>> window, and only containing items pertinent to the window. e.g. for a
>> simple window, the File menu might only contain the "Close" item.
>>
>> I'm trying to figure out how typical Windows apps behave.
>>
>> Paul R.
>>
>> _______________________________________________