Re: NetBeans and ScreenMenubar on Mac

Bryan Boone wrote:
> Jesse Glick wrote:
> 
>> Ana von Klopp wrote:
>>
>>> For what it's worth, I see a lot of problems with this in the regular
>>> case also. For example, some actions are always grayed out (on a 
>>> method, the "Move to other class" is never enabled for me for
>>> example).
>>
>>
>>
>> "Move Class" you mean? Enabled for me at the top of a file. Possibly a 
>> bug if it is disabled within the file, but I don't know how it is 
>> intended to work exactly. Anyway this probably has nothing to do with 
>> any problems with the screen menu bar on Macs.
>>
>> -J.
>>
> Jesse, I ran a simple test with my application.  It looks like 
> popupMenuWillBecomeVisible isn't getting called for the screen menubar. 
>  I validate (enable/disable) menus actions in my app when the menu is 
> activated (popupMenuWillBecomeVisible is called).  I think that's what 
> you guys do, too.
> You guys have probably more clout at getting this one fixed than I do;)
> They may have it fixed in Tiger (JDK 1.5), but I don't know since I have
> Panther:
> java version "1.4.2_05"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_05-141.3)
> Java HotSpot(TM) Client VM (build 1.4.2-38, mixed mode)
> -Bryan

This is pretty much a known problem, re the screen menu bar.  For 
updating menus dynamically, I did get the secret from an Apple engineer: 
  Listen on the ButtonModel of the JMenu.  I've confirmed that it does 
work with the screen menu bar and elsewhere.

The real problem is two things:  1.  JInlineMenu, which is a menu item 
that is sometimes a menu item, sometimes several - it treats Swing menus 
as generic Swing containers, which works for standard look and feels, 
but misbehaves badly on the mac;  and Actions.SubMenu, which is a JMenu 
which sometimes has the UI delegate of a JMenu, sometimes that of a 
JMenuItem (it's how the Paste menu item can morph into Paste As and have 
subitems some of the time).

There are other ways to do both of these things - basically just add and 
remove the appropriate elements on the fly, rather than trying to keep a 
persistent component that serves as being two things at once.  However, 
these classes are also part of the API, so replacing them compatibly is 
extremely difficult - and in the case of Actions.SubMenu, the code 
involved is truly eye-crossing (I took a couple stabs at detangling it 
and gave up).

There is a prototype that works on all platforms, of a replacement for 
the entire main menu infrastructure, in contrib/menus, which I put 
together and wrote lots of tests for to ensure it works both on the 
screen menu and on regular L&F's.  However, there's still the matter of 
bridging the existing actions to it.  So it's really just a question of 
resources and possibly willingness to break compatibility.

-Tim