[e-lang] E and SWT
Sat, 27 Jul 2002 16:18:38 -0700
Just to give everyone an update on what I've been doing lately to E, I've been
experimenting with the Standard Widget Kit(SWT) from IBM (at www.eclipse.org)
as a replacement for Swing for E. My experiments have born out the early hope
that SWT would indeed be a significant improvement. I have built an SWT based
version of the eBrowser development environment. While this version of
eBrowser is not fully operational because the SWT display thread needs to be
integrated with the E event queue, all the user interface elements are in
place, and I have interesting screenshots for anyone interested of
SWTbrowser versus Swingbrowser under both Windows and Linux.
For anyone considering switching from Swing to SWT, whether using E or Java,
here is my assessment. The overall summary is that SWT follows the 80-20
rule: it gives you about 80% of the useful functionality of Swing for 20% of
the cost. Also, SWT is not fundamentally broken on Linux, while Swing is.
Here are the details:
Advantages of Swing:
-- Swing has automated garbage collection. SWT requires manual garbage
-- Swing has a more consistent generalized architecture, which allows one to
doing some interesting things in the user interface. Since every JComponent
is a container, it allows you to do some cool stuff with widgets inside of
widgets, and do complex layouts inside of lists and tables. An item inside an
SWT list can have an icon and a string, and that is it.
-- Swing does have more functionality in addition to more generality. The
thing I miss most in SWT is, ironically, a piece of Swing that is laughably
broken: the HTML rendering powers of the JEditorPane and the JLabel. While
the HTML rendering in these widgets does not survive 8 seconds when exposed
to the chaos of the Web, as a quick and easy way to render a styled text box
it is very useful. I have built a TTML loader for the SWT StyledText widget
(TTML stands for Term Tree Markup Language, for example, in E,
term`text("This text is normal. ", b("This text is bold and",
color(0,255,0,"this text is bold green")))`
produces bold and green text). The TTML loader is useful, but it is not as
good as even the poor HTML renderers in Swing.
-- Swing is easier to install, which is to say, it is automatically installed
when you install java. SWT requires additional installation; markm is already
shuddering at the thought of enhancing the E installation to support SWT :-)
-- Swing is in production deployment for Mac and FreeBSD. SWT for Mac and
FreeBSD is still in the works.
Advantages of SWT:
-- Garbage collection works correctly. For Swing, the only platform that does
not leak memory from discarded user interface widgets is the Mac. On Windows
the memory leak is an irritation if you work in E programs all day long. On
Linux it is a disaster, severely restricting the amount of time you can keep
a ui-intensive E program running. With SWT, the garbage collection may be
manual, but it is effective. The further good news is that SWT has been very
carefully designed around the best manual garbage collection strategy I have
-- SWT Widget footprints are smaller. Under Linux, a swtBrowser goes from 14MB
with one browser window open to 15MB with 3 windows open. A SwingBrowser goes
from 14 to 20.
-- SWT Platform look and feel is correct in every detail. On Windows, the
fonts are right, the width of the splitter bars is correct, the dialog boxes
have all the right buttons, and the popup and dropdown menus all close
correctly when the window loses the focus. In short, the swtBrowser looks
like it was written with Visual C++. Hallelujah. On Linux, SWT uses a motif
look and feel (a gtk version is coming, though that is irrelevant to me as
KDE user). While SWT Motif still looks funky on a KDE desktop, it is a
tremendous improvement on the JavaSoft metal l&f, which is the ugliest bit of
user interface design since the death of the lime-green-on-black 80-character
terminal in the mid 80s.
-- SWT is a fraction of the size. I haven't counted the methods or classes,
but there are a total of 5 SWT packages, versus over 20 for Swing+AWT. So
there is a lot less to learn, and for E, a lot less to tame.
-- SWT is much simpler to learn and use. This was most striking when
implementing drag-drop. Swing dnd is so marvelous in its generality, it is
hard to find the classes you actually need to worry about: the dragsource and
droptarget are completely buried under a welter of dragGestureRecognizers and
DataFlavors. In SWT, I just took a brief look at the javadoc for the dnd
package and implemented it for swtBrowser to receive files off the desktop
(works like a charm on Windows, doesn't interface with the KDE/QT drag/drop
system; neither does Swing). Dnd also works better with SWT: the never-seen
dragGestureRecognizer for SWT (which I presume is platform specific native
code) just does the right thing, whereas sometimes Swing gets confused about
what to drag and when to drop.
It seems clear that E should move to SWT. I have done a quick taming pass over
SWT. I estimate that this tamed version of SWT has no more than 1/8th as many
security vulnerabilities as the taming pass I made over Swing, which means
there are probably two or three serious vulnerabilities waiting to get caught
by someone doing a more careful pass. I compute this using the following
-- SWT is no more than half the size of Swing,
-- SWT is no more than half the complexity of Swing, and
-- I am no more than half as foolish when taming as I was when I tamed Swing.
This gives us a factor of 1/8th for the expected number of vulnerabilities :-)