[e-lang] E and SWT

[marcs]

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 
collection.

-- 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 
ever seen. 

-- 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.

Conclusions:

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 
conservative algorithm:

-- 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 :-)

--marcs