<AWT Dev> [8] Request for review: 8017189 [macosx] AWT program menu disabled on Mac

[Sergey Bylokhov]

Hi, Gregg.
On 22.07.2013 19:08, Gregg Wonderly wrote:
> As a user of MACOS-X and Windows and Linux and as a developer, I'd 
> really like to suggest that the issue with MACOS-X, is that the menu 
> is an application thing, not a window thing.  The problem with Java on 
> OS-X, is that Java Menus are "window things", not application things.  
> By promoting menus out of windows and onto the menu bar, the single 
> window application has a convenient transformation into an OS-X 
> application.   However, as soon as you introduce a modal window, such 
> as a dialog, which would disable the main window access, and thus make 
> the menu bar there, unusable, the OS-X menu bar extraction, from the 
> main window, becomes problematic.
According to documentation of modal dialogs: "Modal dialogs block all 
input to some top-level windows" including the menu. So this is correct 
behavior.
After the fix for 8010906 the modal dialogs disable parent menubar 
instead of removing.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010906
This is a small trade-off without violating the specification

> It seems to me, that what should actually happen, is that any "window" 
> in java, that is "current", should have it's menu bar pushed in to the 
> OS-X menubar.   If I have two or more, non-modal windows, and I click 
> between them, I'd expect to have access to two or more distinct menu 
> bars just like I would on other OSes using Java.  A modal window would 
> just cause it's own menu bar to be used, and that would greatly 
> simplify and unify the behavior to work as the application has been 
> designed.
>
> Gregg Wonderly
>
> On 7/22/2013 9:02 AM, Sergey Bylokhov wrote:
>> Hi, Leonid.
>> Is seems to me that this is another issue, and both jdk6jdk8 behave 
>> incorrectly.
>> When the window with mainmenubar is disposed, menu should be removed, 
>> because it doesn't make sense in this case. So dispose of the window 
>> should be fixed.
>> What do you think?
>>
>> On 22.07.2013 16:57, Leonid Romanov wrote:
>>> Hi.
>>> Here is a test case that, with your patch applied, works differently 
>>> than JDK 6:
>>> 1. Show JFrame with a menu
>>> 2.  Create a modal dialog with the frame as a parent
>>> 3. Dispose the frame
>>> 4. Make dialog visible
>>>
>>> With JDK 6, the dialog's menu will be disabled. With JDK 8, it will 
>>> be enabled.  So, formally, we've got a regression. I'm not sure 
>>> whether it is worth fixing, because it looks like a corner case, but 
>>> still.
>>>
>>> On Jul 19, 2013, at 10:15 PM, Sergey Bylokhov 
>>> <Sergey.Bylokhov at oracle.com> wrote:
>>>
>>>> Hello,
>>>> Please review the fix for jdk 8 and 7u40.
>>>> The fix for JDK-8010906 don't take into account situation then 
>>>> first parent has no menu bar, but the second has.
>>>> So it introduce the next scenario:
>>>> #1. Open the window with File menu.
>>>> #2. Open modal dialog1 =>File menu is disabled
>>>> #3. Open modal dialog2 =>File menu disappears
>>>> #4. Close dialog two
>>>> #5. Close dialog one. File menu reappears, but File still disabled
>>>>
>>>> The steps #3. occurred, because CMenuBar.activate resets the 
>>>> current menubar if a passed javaMenuBar is null.
>>>> The steps #5. occurred, because at step #3 we do not remove our 
>>>> nsmenu from the deleted NSMenuItem, when the appropriate NSMenuItem 
>>>> removed from mainMenu. So at step #5 we got a situation, when our 
>>>> nsmenu was added to the two different nsmenuitems: old(disabled) 
>>>> and new(enabled).
>>>>
>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017189
>>>> Webrev can be found at: 
>>>> http://cr.openjdk.java.net/~serb/8017189/webrev.00
>>>>
>>>> -- 
>>>> Best regards, Sergey.
>>>>
>>
>>
>


-- 
Best regards, Sergey.