David, Thank you very much for such an expansive response. Currently a thread-safe Swing alternative is using the Jambi bindings for Qt. I neglected to provide a link to details before so here it is: <http://doc.trolltech.com/qtjambi-4.4/html/com/trolltech/qt/qtjambi-index.html> http://doc.trolltech.com/qtjambi-4.4/html/com/trolltech/qt/qtjambi-index.html Although this solution does add a layer of uncertainty, and may not warrant the installation hassles. Personally, I rarely do GUI work, but I intend to do alot very soon. Since my last post I communicated with a guy at Sun specifically about AWT, and now, for purely academic purposes, I will be writing an AWT & Swing replacement utilising XToolkit bound to a modified Xlib with Solaris being the target system. (phew, try and say that ten times fast) Perhaps its needless to say, but the project it will have a rather esoteric approach. Anyways, I hope to have the design finished by New Years. Thanks again David for your response.
Cheers, Ande 2008/10/11 David Powell <[EMAIL PROTECTED]> > > > > I'm just delving into the details of how Swing is implemented at > > the moment, can't say I agree with half of the "design" decisions > > myself. Swing isn't thread safe, although AWT is to my knowledge, > > Actually, AWT isn't thread-safe either. Documentation about the fact > seems pretty hard to find. From what I can gather, in Java 1.1, AWT > claimed to be thread-safe, but there were problems with races and > deadlocks, therefore in Java 1.2 and above AWT doesn't claim to be > thread-safe. AWT does seem to mostly work if you call it from multiple > threads. > > Some discussion here: > > > http://www.elharo.com/blog/software-development/java/2006/11/10/awt-on-the-event-dispatch-thread/ > > A brief official reference here: > > > http://java.sun.com/j2se/1.5.0/docs/guide/deployment/deployment-guide/applet-compatibility.html > > Also here: > > > http://web.archive.org/web/20060816013814/http://java.sun.com/docs/books/tutorial/uiswing/misc/threads.html > > > > There's some more info here about why multi-threaded GUI toolkits > aren't such a good idea: > > http://weblogs.java.net/blog/kgh/archive/2004/10/multithreaded_t.html > > Restricting GUI objects to only work from one thread is done so that > they don't need to use locking, which makes them faster and less prone > to bugs. Lots of GUI toolkits do this, eg: Win32, .NET, SWT. Allowing > objects to be accessed from multiple threads makes things slightly > easier for clients, but isn't really going to improve performance. > > Swing does have some annoying aspects of its design (its fake platform > UI isn't all that convincing), but I don't think that the > single-threaded access model is that bad a thing. > > -- > Dave > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
