Always reading bits...
Its the shadows and reflections cast from the future that interest me.
Restaurant Reviews
Flickr - Latest Photos
cld
Eclipse On MacOS X : Broken - Another SWT-Related Story
posted Monday, 4 April 2005
All of this is being also seen in other user experiences and with other plugins (that use Apache Digester and OGNL). This was actually summarized in earlier closed bug 53790 by the simple statement (#16) that interoperability between Swing/AWT and SWT isn't supported on MacOS X. That's it. That short sentence has a deep effect on MacOS Eclipse developers - they end up not able to use some UI Builders, plugins that make use of Swing/AWT and numerous other useful applications and technologies. One of the developers suggested even Eclipse's own Visual Editor is not supported on MacOS X. You can read the requirements here (see Visual Editor Runtime). It's actually quite interesting, not only is Eclipse Visual Editor not supported on MacOS - Linux+Motif also is not supported at the time of this writing. I note that some MacOS X users have VE running. According to these developers VE does not have the same issue as the above bug. The unfortunate reality is that many SWT-based apps that try to interoperate with Swing/AWT hang on MacOS X. I would love to know when they will fix this bug because some of the comments in the 67384 bug report do not appear to be encouraging. So another myth is highlighted - the myth that developing code using the SWT will naturally run on other platforms. This certainly does not appear to be the case. This whole scene is very different from Swing. Take the NetBeans "archive" install bits, install them on Solaris x86, pointing it at a Solaris x86 JVM, both 32-bit and 64, NetBeans runs. Take that same directory to Linux, point it at a JVM (JRockit, Hotspot or IBM) it will run. Take that same directory to Windows, point it at JVM (JRockit or Hotspot) and it will run. |
||||||||||||||||||
| So here we are again. SWT
duplicating poorly what Swing already does well. Instead of a large
collaborative effort on Swing and Java2D, that moves standard Java APIs
forward - IBM and Eclipse.org have thrown resources at SWT. The
result not surprisingly is serious bugs like 37683
and 67384.
67684
is symptomatic of the technical difficulty of keeping two windowing
toolkits live
side-by-side. They have to cooperate at all levels - event loop,
drawing primitives, threading models, etc. So yes it is possible
to get to a state of demo quality - but production quality ? Obviously
not. At EclipseCon 2005 in response to a question of how SWT and
AWT interoperate - a noted SWT developer stated that the code was a
pile of band-aids that happened to work. This is hardly something you want to
base your livelihood on. And
apparently it doesn't happen to work. So, you have a broken
MacOS Panther Eclipse version. With a Tiger (MacOS
10.4) on the way with a new JVM (J2SE 5.0) along with that. And
the news doesn't get better. Not far behind that is Longhorn from
Microsoft. For each new version of MacOS, Windows, Linux and Unix
UI toolkits there needs to be corresponding new versions of SWT. On some Unix platforms only antiquated SWT-Motif versions exist instead of SWT-GTK.
It actually gets much worse - many tools that work on other platforms do not work under MacOS X. Today. The amount of work
necessary to get SWT to where Swing/AWT/Java2D is today is tremendous -
and toward what end ? The performance and UI fidelity
of emulated and native toolkits has blurred - Swing has become
increasingly faster and Swing's GUI fidelity is now good enough -
especially when SWT has examples of UI fidelity like SWT-Motif. And even more unfortunate for SWT proponents is the fact that the Eclipse community is now talking about how slow Eclipse is and comparing it to Swing-based IDEs. One can
imagine, Eclipse.org tiring of this and simply porting SWT or Eclipse to Swing to
get both a performance and quality boost. At least that would
make it a cross-platform working, clean and compatible solution. |
