<AWT Dev> Review request for 7132692: [macosx] Class com.apple.eawt not functioning
anthony.petrov at oracle.com
Thu Feb 16 04:30:16 PST 2012
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,
>> On 2/13/2012 6:53 PM, Anthony Petrov wrote:
>>> Please review a fix for http://bugs.sun.com/view_bug.do?bug_id=7132692
>>> 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,
More information about the macosx-port-dev