Fix looks fine.
On 26.07.2013 15:45, Leonid Romanov wrote:
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.
--
Best regards, Sergey.
