Here is a second version of the fix which addresses both Anthony and Sergey comments:
http://cr.openjdk.java.net/~leonidr/8007267/webrev.01/ On Jul 26, 2013, at 2:57 PM, Sergey Bylokhov <sergey.bylok...@oracle.com> wrote: > Hi, Leonid. > Please confirm that flirk is not a problem here. > Also looks like in the windowDidBecomeKey: > 557 if (menuBar == nil) { > 558 menuBar = [[ApplicationDelegate sharedDelegate] defaultMenuBar]; > 559 } > 560 > 561 [CMenuBar activate:menuBar modallyDisabled:!awtWindow.isEnabled]; > > defaultMenuBar should not depends from the awtWindow.isEnabled > > 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. >
