[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-swt-dev] Cocoa SWT_AWT issues, and a new API proposal
|
On Sep 18, 2009, at 12:11 PM, Christopher Deckers wrote:
> Hi Scott,
>
> I just had a look at
> http://dev.eclipse.org/newslists/news.eclipse.tools/msg09000.html and
> it is not a standard case: Swing components are manipulated outside of
> the EDT. Also, Snipet 157 is an applet, which is not the most
> important test case.
Okay, I can go along with that. The newsgroup post was very old, so I
wasn't sure how much things had changed. And, I knew the Applet case
was going to be odd.
>> - Creating a Display from the AWT event dispatch thread causes the
>> EDT
>> to be associated with the Display.
> The standard case probably looks like this:
> https://bugs.eclipse.org/bugs/attachment.cgi?id=147590
>
> A few notes: display is created in the main method, as recommended by
> SWT. The Swing UI is created in the EDT, as recommended by AWT/Swing.
Now we are getting somewhere. Thanks for posting that.
>> - There are some operations that must happen on the AppKit thread,
>> like resizing.
>
> I am not sure I understand enough the various threads that we have to
> cope with on the Cocoa. Is AppKit the main thread/SWT event thread?
If you launch the application with -XstartOnMainThread, yes, that is
the case. That is the normal use case for SWT applications. If you do
not specify that argument you are starting up a Swing/AWT application
and the 'main thread' is actually a second thread spawned by the java
command-line tool. The AppKit thread is not visible to the user in
that case.
The more I look at this, however, it _should_ work. If you use -
XstartOnFirstThread and launch a Swing/AWT application, the AWT
assumes that something else is running an NSApplication on its behalf.
That's what we're doing in the readAndDispatch/sleep loop.
If I try this example with the reference to SWT_AWT.new_Shell removed
in Carbon, the JFrame shows up. In Cocoa 3.5 it does not. If I
interrupt it with the debugger, it eventually does show up. That means
readAndDispatch/sleep isn't doing something the AWT is expecting.
I'm going to try experimenting with our NSApplication overrides so
that the AWT's NSApplication gets a chance to look at the message,
even if we process it. NSApplicationAWT may need to do something
special and we are preventing it from happening.
-- Scott
