SwingWT uses Eclipse’s SWT to offer native host-widgets for Java applications. Screenshot.
Swing-Applications with Native-Widgets: SwingWT
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Thoughts ?
Since the release of Jaguar, Swing widgets are already translated into Mac OS X Aqua widgets automatically when the Java app runs. In some cases, this is not the case, but in my experiences the translation between Swing and Aqua happens more often than not.
I find Swing to be ugly and slow. I also find swing to be one of the best designed and easiest to use GUI toolkits from an API and OO point of view. I’ve started experimenting with wx4j (java bindings for the wxWindows toolkit). I decided to give wx4j a try over SWT because wxWindows is a robust and mature platform independent GUI toolkit. SWT is re-inventing the wheel (or at least part of the wheel). So far my app looks much better, and feels more responsive. But wx4j isn’t yet a full set of bindings to wxWindows. You also have to do a little more work to use it than you need to use Swing, mostly becuase the MVC patter isn’t prevasive as it is in Swing. A GUI toolkit with the API of Swing, but with the speed and good looks of native widgets would be super cool.
All native toolkits for Java are a step backwards from Swing. It brings you back to the aweful days of AWT with weird garbage collection problems and applications crashing because of some native dependencies on some target platform. The whole premise of Java is to be able to deploy the application seamlessly on multiple platform and the native toolkits are not going to make it easy. Thankfully Swing resolved all of that and you don’t have to worry about those problems any more. Yes it is easy to look at these screenshots of very small and practically useless applications and say “it looks cute”, but in reality looks don’t mean a whole lot and the ability to develop and deploy the application with least amount of problems is much more important.
You says Swing is conceptually better than native widget UI toolkit because it ensure that it will work on every target. But to work on any target, the JVM as to be well implemented on this target and especially AWT wich use some native code. If the JVM where properly implemented with the SWT library, there would be no reason SWT be less stable than SWING/AWT.
Anyway, the look and fell really realy mather. Nobody would use Micosoft office nowoday’s if it looked like NetBeans.
> If the JVM where properly implemented with the SWT library, there would be no reason SWT be less stable than SWING/AWT.
Yes, but it is much harder to reliably implement a JVM with native toolkits on multiple platforms that have their own way of dealing with onscreen graphics. Theoretically everything is possible, it is the amount of effort and quality of the result that matters in the end.
Anonymous: Yes, but it is much harder to reliably implement a JVM with native toolkits on multiple platforms …
From looking at the site, they don’t propose to implement these toolkits themselves. They just propose allowing Swing applications that others have already written use the SWT native toolkits that others have already implemented. These platforms may have their own way of dealing with graphics but the SWT toolkits have already abstracted most of that away from the API – SwingWT just abstracts away the rest, making it look to apps like just another Swing implementation.
There would be no need for the SwingWT people to develop any native widgets on any platform. Apps written to the Swing toolkit can just use SWT widgets where they already exist, and Swing widgets where they don’t. I don’t see any downside here as long as the additional API wrapper doesn’t slow things down too much, or at least slower than straight Swing.
I do find it worrisome that there aren’t any non-Linux/GTK screenshots on their site, though. It was a little disappointing to follow references to “running on your platform with native widgets” and not see my platform. Am I supposed to just take their word for it that they support other platforms?
>I do find it worrisome that there aren’t any non-Linux/GTK screenshots on their site, though. It was a little disappointing to follow references to “running on your platform with native widgets” and not see my platform. Am I supposed to just take their word for it that they support other platforms?
I’ve used SwingWT with Windows (Win2k) starting from version 0.70 to the latest without any noticable differences from the GTK+ version. I’d say that the reason for the GTK+ screenshots is that the SwingWT author uses Linux and GTK+ for development (Eclipse GTK+ actually), so that’s what he has available.
I didn’t look at the specifics yet but does anyone knows about the possibility of adapting existing closed source applications to use the SwingWT?
The reason I ask is: can I use Sun NetBeans using SwingWT? One of the reasons I dislike NetBeans so much is because of the ugly Swing interface, but if it smells like SWT it would become a really strong Eclipse contender.
What do you think?
How does SwingWT deals with the problem of disposing of native resources?
Your code disposes of most native resources (think about it – you call JInternalFrame/JFrame/Dialog/Window subclass.dispose() somewhere down the line).
As for Fonts, Colors, Images, Graphic Contexts etc. SwingWT uses finalizer based destructors (with an additional dispose() method so you can destroy them by hand). It also uses a timed interval on the event pump to trigger the finalizers, along with shutdown hooks to guarantee that if you don’t dispose of native resources when you’re finished, they will be disposed for you as fast as possible and they *will* be destroyed.
Hope this helps,
Bob
P.S. I’m the author of SwingWT 🙂
Oh, and the author of SWTSwing has come up with a bootstrap classloading hack to substitute SwingWT for “real” Swing on the fly so it may be possible to run NetBeans (and any Swing app) with SwingWT without recompilation.
I am not crazy enough to try this yet, but it will be possible at some point soon 🙂
Bob