Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Possible work-around to SWT/AWT event thread problems

Without getting tangled-up but trying to answer:

I just launched eclipse 3.01 on Mac OS Tiger.

I opened a project which has this class:

public class ASwingGui extends javax.swing.JFrame

This frame has 90% of the AWT/Swing widgets.

I launched a debug session from eclipse.

Eclipse works normally and the JFrame with its widgetry works normally.

I can use the debugger thus implicitly generating events between a SWT and a Swing app.

If I close eclipse while debugging, the JFrame closes accordingly.

No dock/mouse/icon/event handler confusion (suggested as a possible pitfall)

At this point we can say that we have a general case where a SWT based app and a AWT/Swing app run concurrently in Mac OS Tiger.

The work-around to the eclipse bug in question was: see if an eclipse plug-in  that uses AWT/SWing can use the same principle: a dual process to avoid the fight for thread #0.

It seems that any plug-in which can take the performance hit should be able to achieve the same results.

José


On 8/19/05, Tim Boudreau < email@hidden> wrote:
>
> On Aug 16, 2005, at 8:21 PM, Jose Cornado wrote:
>
> > I managed to read most of the eclipse's bug 67384 thread. So if I am
> > not summarizing this correctly, let me know:
> >
> > 1) OS X requires that the UI event thread lives in thread #0.
>
> (Any reply from me on this thread is suspect, but...)
>
> I suspect integrating anything beyond a toy integration of Swing
> components into SWT is going to run into pretty serious trouble;  bear
> in mind that the threading code for most multithreaded Swing apps lives
> and dies by SwingUtilities.isEventDispatchThread() and
> SwingUtilities.invokeLater();  it's provably dangerous to access (or
> even construct) Swing components from other threads than the event
> dispatch thread (with a minor exception if the app has yet to display
> any GUI at all).  The odds of keeping two guis with their own distinct
> event loops sandboxed so well that code from one toolkit's event thread
> never enters the other toolkit's components' methods except on the
> other toolkit's event thread are pretty slim unless the code was
> written from the ground up with that in mind.  Without that, well, you
> get something that looks like it works, and even probably does work a
> good deal of the time - but not really something you want to use in
> production code.
>
> -Tim
>
>  _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Java-dev mailing list      (email@hidden)
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/java-dev/email@hidden
>
> This email sent to email@hidden
> 
 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden

This email sent to email@hidden
References: 
 >eclipse plug-in development in Tiger OS (From: Jose Cornado <email@hidden>)
 >Re: eclipse plug-in development in Tiger OS (From: Jose Cornado <email@hidden>)
 >Re: eclipse plug-in development in Tiger OS (From: Jose Cornado <email@hidden>)
 >Possible work-around to SWT/AWT event thread problems (From: Jose Cornado <email@hidden>)
 >Re: Possible work-around to SWT/AWT event thread problems (From: Tim Boudreau <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.