Doing this would introduce the dependency between our regular menu code and
eawt, which is kinda optional now. I'd like to avoid it.
On Jul 26, 2013, at 2:59 PM, Sergey Bylokhov <sergey.bylok...@oracle.com> wrote:
> Hi, Leonid.
> Probably it would be easy to change CMenuBar.activate/deactivate? instead of
> their usage?
>
> On 26.07.2013 12:56, Anthony Petrov wrote:
>> Hi Leonid,
>>
>> AWTWindow.m
>>> 568 - (void) windowDidResignKey: (NSNotification *) notification {
>>> 572 [self.javaMenuBar deactivate];
>>> 574 CMenuBar* defaultMenu = [[ApplicationDelegate sharedDelegate]
>>> defaultMenuBar];
>>> 575 if (defaultMenu != nil) {
>>> 576 [CMenuBar activate:defaultMenu modallyDisabled:NO];
>>> 577 }
>>
>> Note that this may cause brief menu flickering if the very next event is
>> windowDidBecomeKey for another window with a non-null menu bar. But we
>> really can't predict whether a window belonging to our app will receive
>> focus or not, so there doesn't seem to be a better way to handle this
>> situation anyway. I'd suggest to add a comment here stating that the problem
>> is known.
>>
>> The fix looks fine otherwise. Please consider it approved.
>>
>> --
>> best regards,
>> Anthony
>>
>> On 07/26/2013 04:54 AM, Leonid Romanov wrote:
>>> Hi,
>>> Please review a fix for 8007267: [macosx]
>>> com.apple.eawt.Application.setDefaultMenuBar is not working. It doesn't
>>> work because a bunch of code required to make it work is commented out. So,
>>> I've uncommented it, but since it isn't enough, I've also done a number of
>>> additional minor modifications.
>>>
>>> Bug: http://bugs.sun.com/view_bug.do?bug_id=8007267
>>> webrev: http://cr.openjdk.java.net/~leonidr/8007267/webrev.00/
>>>
>>> Thanks,
>>> Leonid.
>>>
>
>
> --
> Best regards, Sergey.
>
