Hi Artem,

Thanks for taking a look at the fix.

On 02/16/12 14:32, Artem Ananiev wrote:
On 2/14/2012 5:25 PM, Anthony Petrov wrote:
Could anyone please review the fix?

I'm not the right person to review, so probably a stupid question. In
AWTStarter -start:swtMode:swtModeForWebStart method, if onMainThread is
YES, we call [st starter:args]. It in turn synchronously calls
[NSApplicationAWT runAWTLoopWithApp: app], which should never return. So
when the application delegate set in this case?

If onMainThread is YES, then we must be running in the swt_compatible mode (see a check for this at line 430). In this case AWT must be initialized only *after* SWT has started its event loop. Indeed, how else could we possibly start AWT from the main thread if there were not an event loop spinning yet?

This leads to the [app isRunning] returning YES at line 356, and as such we don't start up our own event loop but rather follow the 'else' branch of the if statement, and subsequently return from -starter:. After that the +start: will install our application delegate correctly.

--
best regards,
Anthony


Thanks,

Artem

--
best regards,
Anthony

On 2/13/2012 6:53 PM, Anthony Petrov wrote:
Hello,

Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7132692
at:

http://cr.openjdk.java.net/~anthony/x-16-eawt-7132692.0/

With this fix we postpone the initializing of an instance of the
ApplicationDelegate class and setting the delegate to the NSApp until
after the application itself has been fully initialized. The
QueuingApplicationDelegate in libosxapp.dylib will queue all incoming
notifications and resend them to the real ApplicationDelegate once
it's installed.

Note that it is still not completely clear to me why we must postpone
creating the delegate. It seems that it may be somehow related to
loading the nib file which is happening in NSApplicationAWT
-finishLaunching: method.

Given that:

1) the QAD ensures we don't miss any notifications,
2) the test application starts working correctly after this patch
(i.e. the About, Preferences, and Quit menu items generate the
expected eawt events), and
3) there doesn't appear to be an obvious requirement for the
ApplicationDelegate to be initialized earlier,

I consider this fix is OK. Also, it seems that the fix resolves
7130377 ([macosx] Adding Preferences menu results in NPE) as well.

--
best regards,
Anthony

Reply via email to