Let's recall the boundaries for this series. We're looking at GUI toolkits applicable to a broad range of office automation and engineering tasks, including system administration, medium-duty engineering automation and analysis, point-of-sale transactions, and so on.
Widget set is still the rough synonym for
toolkit in some domains. We'll leave specialized three-dimensional, virtual reality (VR), and gaming toolkits for another day, but note that the general-purpose toolkits we discuss have been the basis for many fine games and VR projects.
We also require that our toolkits be portable at least across the leading Unix and Windows platforms, and across a range of conventional development languages. Several fascinating GUI models, including DrScheme, Clean, NeXT, MetaCard, a couple of different Smalltalk and Forth libraries, Delphi, and G2, exhibit remarkable productivity under at least some circumstances. These all deserve consideration at another time; however, they don't fit the current series.
Web wins out
Unlikely as it would have seemed a decade ago, the real winner of the widget wars is the Web. The single toolkit we find ourselves most often using is the one HTML specifies.
Of course, thousands of books describe Web applications or selected aspects of them. Distill from these a pair of conclusions that fit our comparison:
- Deployment matters. Numerous times, we've heard professional developers moan about how impoverished and inadequate browsers are as a GUI. It doesn't matter, though, to the decision-makers who end up buying Web solutions that they understand rather than the fragile, handcrafted elaborations that programmers often prefer.
Even if you know you're going to a different technology for a final delivery, it's OK to prototype applications with a simple Web design. You can often learn crucial usability results with that first rough draft.
- The Web can do more than you realize. We periodically document in our Regular Expressions column the wonderful things that experts do with JavaScript, plug-ins, and an assortment of server-side facilities. The growing acceptance of DHTML gives Web applications approximately the full range of GUI capabilities that other toolkits enjoy.
Plenty of the world's applications require no more than a bit of Web sophistication. If this kind of work appeals to you, you'll be busy for a long time.
Notice that this wrap-up to our series is as textual as all the other installments. We've used no graphics in a discussion of graphical toolkits! This is because we're comparing the toolkits at the character level, which is of greater significance than cosmetic appearance. A different series of articles might justly compare the fashions of button details in Netscape 3, Internet Explorer 4, Opera, and Motif. Such a focus would help some projects more than our series does.
Our aim is to help developers get a feel for different programming libraries. The on-screen appearance of a typical Web application has changed over time, and admits a great deal of customization in the hands of a clever practitioner. Through all these changes, though, the Web's essence has been to model stateless, transaction-oriented, client-server operations with particular restrictions on the messages passed. That's the inner nature this series seeks to convey.
Java: Capable, widely accepted, and heavy
Java's Abstract Windowing Toolkit (AWT) and Swing are standard in many organizations. As with Web applications, there's extensive literature on these libraries, an abundance of vendors providing training, and at least nominal standardization in many US universities on Java as a teaching vehicle.
We have reservations about Java, particularly for GUI work. There's a lot to like about Swing's engineering. However, the technology trade-offs Swing embodies consistently fit our needs less comfortably than the toolkits we've covered in this series. Java is nearly unique in being able to specify rotating text in Arabic script with standard options. The predictable consequence of this high level of generality is that Java is relatively cumbersome for more common operations.
When we do choose Swing or AWT, we make a point of scripting an application together with Python, Tcl, or one of several other languages that manage Java classes expertly. We find these languages far more convenient and responsive for the typical development cycles of GUI applications than for Java itself. Even a good Java integrated development environment (IDE) bogs down when managing a large GUI project on midlevel equipment. In this regard, the scripting languages provide a more scaleable workplace, where it's quick to test small changes, independent of the scope of the entire project.
FOX is fast
Closer to traditional GUI practices are toolkits such as free objects for X (FOX) and Fltk. FOX emphasizes performance and portability; many developers like it because its incarnation on Windows looks at-home. Jeroen van der Zijp created FOX in mid-1997, first for Linux and then for other Unix ports. This is much like the history of several other toolkits.
However, the portability of FOX has already matured more than that of, for example, GTK+. As we described earlier in this series, it might be a few months more before GTK+'s visual appearance meets the expectations of longtime Windows users. Like wxWindows and Qt, FOX exposes a C++ API. Also like those, FOX has a good binding to Python. FOX even binds to Eiffel, and there are hints that Ruby and other languages aren't far behind.
FOX development has emphasized ease of construction of new widgets. It has the economical feel of Tk in its exploitation of sensible defaults. A simple FOX application in C++ is only a few lines, and default geometry is often good enough for simple applications.
FOX makes good use of introspection on display state and a variety of variable linkage. The effect is to make constraint programming a feasible style. With a more traditional toolkit, a programmer typically writes a great deal of application-specific logic to keep the GUI consistent. This might take the form of graying out selections that are invalid in a particular context. FOX simplifies maintenance of this kind of consistency, which often demands a great deal of care when using other toolkits.
FOX's features
Van der Zijp designed a toolkit that other savvy developers enjoy. Orthogonality and consistency are prime FOX values. At the same time, FOX is a rich environment for development. It offers many of the features applications commonly need, including balloon help (or tool tips), single and multiple document interfaces (MDI), status-line information, drag-and-drop functionality, tabs and trees, and a simple persistence mechanism for configuration information that van der Zijp calls the Registry. An event-aware message-passing model is pervasive. Several common algorithms reduce to just a line or two of FOX code, with one object sending another a particular message.
Like most of the toolkits we've profiled, FOX has plans for improved support of alternate character encoding in the near future. As van der Zijp told us, "Internationalization is probably the most pressing weakness at this point ... I hope to address [this] in the next couple of months, however."
FOX's fortunes were originally tied closely to those of van der Zijp's employer, CFD Research. Usage of other toolkits continues to dwarf that of FOX. However, FOX feels different from how it felt 18 months ago. It's acquired a critical mass of users and contributors, and can probably outlive any single patron.
Fltk packs a lot in a small package
Fltk (pronounced full tick) shares many features with FOX. It's a C++ toolkit, built for Digital Domain's Unix projects. It's fast, and relatively small and light: a static linking of a demonstration of every Fltk widget is under 400 KB on x86 Linux. It boasts an associated GUI builder that's currently more advanced than FOX's. While Qt and GTK+ use signals mechanisms for callbacks, Fltk has a more direct model that its fans find easier to program.
The Fl in Fltk derives from forms library, although author Bill Spitzak has fictively cited the Fltk acronym as a back-formation of fast, light toolkit.
Fltk's use doesn't appear to be growing as rapidly as FOX's. Its widget set isn't as rich as those of GTK+ and Qt. Spitzak says that he doesn't "try to use the native toolkit, [but] programs at a very low level. This avoids lots of bugs and makes it very reliable for cross-platform development. It also means the GUI is identical on all platforms."
Bindings for Perl and Python are in development.
XPToolkit: An intimidating API
XPToolkit's personality is closer to Java's than are those of FOX and Fltk. XPToolkit is the toolkit behind the Mozilla browser. A great deal of engineering talent has produced an intimidating and powerful cross-platform API that strikes a high profile. In addition to Mozilla, the celebrated Komodo IDE from ActiveState Tools is built on XPToolkit.
Many developers think of XPToolkit in terms of the Gecko rendering engine at its heart. It's entirely appropriate, though, to consider XPToolkit as another in our lineup of Unix-originated, cross-platform, general-purpose toolkits.
XPToolkit is a C++ library. In the Mozilla organization, XPCOM collects the GUI widgets of XPToolkit along with components for networking, text operations, and so on. Thus the Python binding for XPToolkit is currently available only as part of a larger project called PyXPCOM.
Shopping for your own needs
Authorities too often give the impression that the only GUI toolkits available for Unix work are GTK+ and Qt, or, at other times, that only Motif is good enough for serious applications. Don't be taken in. In fact, there are at least 10 general-purpose toolkits in common use today. Each has applications for which it is best. Good luck deciding which best fits your needs.
