Now blogging at diego's weblog. See you over there!

SWT: first impressions

After spending a couple of days actually using SWT and trying out things, these are my first impressions.

First, for an IDEA-junkie like me it takes a while to adapt to Eclipse. There are a few refactoring functions that just aren't there and the editor behaves just... well, weird. But that's not a huge issue.

Specifically about SWT, it is simple and works reasonably well. However, it is too simple. In fact, it is downright primitive, and it seriously changes the way you think about operating system resources (more specifically, Graphics resources). Maybe that's good, but being used to the idea of Swing, where you can create components or colors or whatever and move them around and pass them between contexts with impunity, it is, well, shocking to, for example, not be able to create a component without a parent.

This is more a change in style (application-oriented, rather than component-oriented). What's a bigger problem is how completely, utterly primitive the tools to deal with graphics are. (Yes, even more primitive than AWT). Take, for example, Fonts. You can create a font (and remember to dispose of it!!) but if you want to calculate the length of a string on that font, you're out of luck. In fact, if you want to calculate the length of anything related to fonts without referencing an existing GC (SWT's Graphics) context, you're out of luck altogether. It can't be done. (While in AWT/Swing you have Toolkit.getDefaultToolkit().getFontMetrics(font)). Even if you do get a FontMetrics with a reference to a GC, the methods you do have are simply pathetic: getAverageCharWidth(). That's it. There's another method in GC to obtain the actual length of a character (getCharWidth) and the length of a string (textExtent). Color management is also bad: essentially the only way to create colors is to use directly the RGB values -- no predefined constants for anything, not WHITE, not BLACK, and no way to do what's so useful in Swing, call a brighter() method to obtain a variant of the color. (And, again, once you create them, they have to be dispose()d of.)

Lists, Trees, Tables and TreeTables are good, and in fact they are easier to use than Swing. But they are wayyy less customizable. For example, you can't insert an arbitrary component on a table. You can only show strings (single line) or images, or other one-line components (like a combobox). More complex components are also lacking. Take, for example, rich text editing or display. While the JEditorKit in Swing might be a massive nightmare, at least it exists. SWT has no equivalent to it. JFace, which is a higher-level library built on top of SWT, is an improvement but not enough.

On the other hand, Eclipse itself is built on SWT and Eclipse does have some of these components. It's not clear, however, how to access them. Documentation is improving, but still lacking.

Now for the good points: the platform is thought as a layer on top of any OS, rather than an independent platform, so it has some simple ways of doing crucial things that the JDK should have added long, long, long ago (think 1996 :-)). Example: launching the default program for a document. In standard Java, you have to resort to ridiculous Runtime.getRuntime().exec() calls that fail half the time and have to be tested in more combinations that is possible. Eclipse, on the other hand, has a handy Program class that lets you obtain the program for a given file extension as follows:Program.findProgram (".html"); and then obtaining the icon (cool!), launching it, etc. Native browser support is currently in beta and it works relatively well, the only question that opens up is whether it's reasonable to resort to platform dependent browsers when you are bringing in all their baggage (I'm thinking of security problems mainly, yes).

And, programs in SWT look fantastic, without a lot of work (Programs in Swing can look fantastic, but only with a lot of work), . In particular if you have ClearType on Win XP, it's a huge improvement, something that can't be done in Swing at all. Even antialiasing doesn't look too good, and it's a hack to use it. Swing can use it though, as the excellent Mac OS X implementation of JDK 1.4.2 shows, so if only Sun would get really into supporting the desktop and doing a reasonable implementation of text rendering for WinXP...

For many people, I think, SWT would be a good choice. For programmers that are only now approaching Java, I get the feeling that it is definitely easier than Swing. OTOH, it's less customizable once you get a handle on it (the reverse of Swing), although I imagine that will be fixed as the platform evolves.

Overall: As Gordon Gekko says in Wall Street: "Mixed emotions Buddy... like Larry Wildman going over a cliff... in my new Maserati."

The Rich Text editor problem is probably the main issue that seems difficult to ignore at the moment, at least for me. Looking into that now (and have been for the last few hours). More later!

Posted by diego on September 9, 2003 at 12:27 PM

Copyright © Diego Doval 2002-2011.