Q regarding threading issues for SWT mode

[steve.x.northover at oracle.com]

A hack yes but you gotta do what you gotta do!  SWT needs to see the 
events as they come in and install its own handlers/delegates (I can 
find out the particulars sometime or you can go browse the source).

The event loop as part of the portable SWT API so an implementation is 
required for each platform.  It is usually the last line of main() and 
is also used for dialogs.

We can take this discussion somewhere else or have it another time or 
when I see you.

Steve

On 15/12/2011 9:27 AM, Anthony Petrov wrote:
> Hi Steve,
>
>> it hammers the class of the existing one
>
> What a hack, huh? :) But since it works, then it's fine.
>
> Although why wouldn't SWT be able to work with our NSApplicationAWT 
> instance then? I heard something about the main menu, but what exactly 
> prevents SWT from modifying the main menu when NSApplicationAWT is in 
> place?
>
> BTW, even if AWT has already started its event loop, what does prevent 
> SWT from simply doing the [performOnMainThread:...] thing to jump in 
> there and do the stuff it needs to do on the AppKit thread?
>
> PS. These questions are unrelated to the initial issue since I've 
> already pushed a fix for it. They arise mostly out of curiosity.
>
> -- 
> best regards,
> Anthony
>
> On 12/14/11 20:50, steve.x.northover at oracle.com wrote:
>> Hey folks,
>>
>> Small point, I believe that SWT does not create it's own NSApplication.
>> Rather it hammers the class of the existing one using objc_setClass()
>> and restores it when SWT exits. You are 100% right that AWT cannot spin
>> an event loop and sit in [NSApplication run].
>>
>> Steve
>>
>> On 14/12/2011 11:08 AM, Scott Kovatch wrote:
>>> On Dec 14, 2011, at 5:10 AM, Anthony Petrov wrote:
>>>
>>>> The only issue that is still unclear to me is when an app is started
>>>> on main thread (to use SWT later), but accesses AWT first (like the
>>>> one mentioned in MACOSX_PORT-720 - it creates an instance of the Font
>>>> class before doing anything else).
>>>>
>>>> In this case we'll create a simple NSApplication instance by means of
>>>> calling the NSApplicationLoad(), however, since Cocoa SWT hasn't
>>>> started its event loop (and hasn't even been initialized yet), [NSApp
>>>> isRunning] will return NO, and hence we'll start an AWT event loop at
>>>> line 354.
>>> Hmm… This should be okay. Have you tried it yet? I believe when you
>>> use NSApplicationLoad() it treats the NSApplication as being in the
>>> running state. At least, I hope that's still the case. Otherwise this
>>> design falls apart. :-\
>>>
>>>> Will SWT be able to take control of the event loop later? Or will it
>>>> be able to put up with AWT spinning its own event loop? Or will it
>>>> simply fail to start up?
>>> No, this is a bad thing. SWT needs to have full control over creating
>>> its own NSApplication and running the event loop. SWT then becomes the
>>> event pump that also dispatches AWT events to AWT windows. That's
>>> because it ignores events not targeted to its windows and lets the
>>> base NSApplication event dispatcher handle it. If the AWT is allowed
>>> to create and run an NSApplicationAWT, it will sit in [NSApplication
>>> run] and never get back out. We'll never get back to the main thread
>>> so the SWT can create a Display.
>>>
>>>> Or do we simply not support such use case? I.e., should we just
>>>> require apps to initialize SWT first prior to using any of the AWT 
>>>> APIs?
>>> This did work with Apple's JDK 6, so I would expect it to continue to
>>> work with 7.
>>>
>>> - Scott