The Standard Widget Toolkit (SWT) is the GUI toolkit used by Eclipse. The same folks that worked on the Common Widget (CW) library for IBM/Smalltalk developed it, this time for Java. Now, it's maintained as part of the Eclipse Platform project and distributed under an open source license, the Eclipse Public License (EPL). One key design point of SWT is that it uses native functionality on each operating system and, at the same time, presents a common, portable API. Joe Winchester, Desktop Java Editor for Java Developer's Journal, asked Steve Northover (SWT Team Lead) recently whether he'd be happy to answer some questions about SWT and, after talking to his colleagues and a few developers, here is the result.

JDJ: SWT supports many different widget toolkits with a common programming API. What's the hardest thing about making all this work?

Steve: Specifying an API that can be implemented natively on a variety of different platforms is very challenging. If you make the wrong choice, you end up with API that is difficult or impossible to implement. To avoid this problem, you need to approach API design with an open mind. Smart programmers want to get the job done and don't care too much about how they do it. Our goal is to get out of the way and get functionality to the programmers. We've been pretty successful doing this and keeping the API reasonable at the same time.

For the implementation, complexity becomes a big issue. It's easy to die the death of 1000 cuts, implementing a native widget toolkit. A sure way to do this is to over-engineer things. We often use the "just do the work" pattern (a favorite of mine). Given two solutions to a problem, I will always choose the one with the fewest classes and lines of code.

Carolyn: The hardest thing is saying "no" to some of the features. Implementation-wise, though, the "devil is in the details."

Silenio: Sometimes it's hard to keep the behavior of the widgets consistent between platforms and still have platform-specific features. For example, on the Macintosh the menu bar is detached from the shell, which is quite different from the other platforms. We needed to come up with a consistent way of integrating this Macintosh feature into the API.

JDJ: When you're dealing with a feature that must be built to work across the different implementations, you have a choice between doing the lowest common denominator, or something you do natively on some platforms and emulated on others. When do you decide which to use, and do you regret any of these decisions?

Steve: There is no decision. If the operating system offers a feature, we make use of it. There's nothing to regret either. We just go ahead and implement whatever is necessary and move on to the next problem.

I'd like to talk about "lowest common denominator" for a minute though. Lowest common denominator is kind of a negative statement. A more positive way to think about it is "highest common multiple." The operating systems provide a lot of functionality that's common, but the native API is different. We expose this functionality, raising the bar rather than lowering it.

JDJ: Do you wish you'd used a different API as your base rather than the Windows one, in particular the way in which window parents can't be changed after construction? For example, if this feature became supported in Windows in the future, it might seem a bit of SWT legacy, whereas if you'd coded reparenting in the C code that SWT sits on top of, you could provide a higher level of API. AWT, for example, allows reparenting by having a wrapper around the peer that can recycle the underlying widget.

Steve: First, I'd like to challenge the notion that SWT is based on the Windows API. It isn't. If you go to MSDN, find the documentation for something like TreeView32 or HDC and check out the SWT API that makes use of these things - you'll see it doesn't look anything like the Windows API. People might get this idea from things like style bits that are found on Windows, but many things in SWT are patterned after other operating systems. For example, the keyboard and mouse API is based on X. We are familiar with many different windowing systems and make API decisions keeping all of them in mind.

Back to reparenting: it's X/Motif that doesn't allow the parent to be changed after a widget is created, not Windows. Whether you are coding in Java, C, or both, either the operating system supports reparenting or it doesn't. If the operating system doesn't support this feature, hiding it in a peer layer doesn't really help that much (actually, it makes it worse because it increases the complexity of the toolkit implementation and adds a level of indirection).

Carolyn: By not having peers, we simplified the toolkit tremendously. Also, peers are somewhat slower and take up more space. And setParent() [mostly] works.

JDJ: What's your favorite native platform to work with, and which do you most loathe having to code on?

Silenio: My favorite platform to work with is the one I have been working on most at the moment. That's because it's the platform I understand best and I can achieve faster results.

Carolyn: Windows has the best doc, so that makes it "friendlier" to work with. We use Google for GTK doc. I don't loathe coding on any of the platforms - the variety is what makes it interesting.

Kevin: Every platform presents unique challenges to SWT so it's difficult to single out any as being better or worse than the others. My favorite platform really depends on the problem that I'm trying to solve.

JDJ: At JavaOne you were walking around with the letters 67384 tatoo'd on your arm. What's the story behind this particular bug?

Florian: SWT contains a piece of code called the SWT_AWT bridge that lets you embed an AWT/Swing component in an SWT shell and vice versa. Prior to 3.2, this didn't work on the Mac due to architectural difficulties. Basically, SWT uses the Carbon API while AWT is implemented in terms of Cocoa, with implications on how UI events are handled. Making the event threads of the two widget toolkits cooperate smoothly and avoiding deadlocks proved to be a rather tricky issue that required changes to both SWT and Apple's Java implementation. The discussion about all of this took place in the aforementioned bug report and spanned a ton of comments from various users. While some people vented their frustration or put forth conspiracy theories, others actually presented ideas on how to fix the problem. In the end, Scott Kovatch, an excellent engineer at Apple, worked out and implemented the necessary steps in cooperation with the SWT team, allowing us to finally mark that bug as "RESOLVED FIXED". Obviously everyone is very happy about that. One user on the bug report even went as far as articulating his excitement over the fix in a rather unique way. For more details, see Bugzilla.

Steve: Although Eclipse and most other SWT applications didn't use AWT/Swing, there were some applications that did and this was holding them back. I hate that because we take pride in helping people ship, not telling them which technology they should use. SWT normally integrates really well with native code but the Mac supports only one GUI thread and both toolkits expected to have their own. That was the technical issue. Somehow, Scott and Silenio got it to work.

Carolyn: "SWT_AWT not implemented for Mac" https://bugs.eclipse.org/bugs/show_bug.cgi?id=67384#c170. It was very exciting to have this one fixed...

JDJ: What's the story behind the naming of the classes CoolBar and CoolItem?

Steve: They're cool. Personally, I hate them.

Carolyn: That's what Microsoft called them. (I know, their control is called a "Rebar," but they used the term CoolBar when describing the control. See this article:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwui/html/msdn_rebar.asp.)

Silenio: Usually when we add a new widget to the toolkit, we decide its name by taking into consideration the names used by all platforms as well as our own ideas. We choose the one that best describes the widget and that's most known by everyone. In this particular case, there were two main options: CoolBar (MFC) and ReBar (Win32). I must admit that CoolBar is strange, but it's a bit better than the other option.