Toolkit libraries and bindings

Most GUI developers will never have to see or cope with the legendary intricacies of Xlib. As we noted earlier in the overview, the X server's features are normally encapsulated by toolkit libraries and language bindings of those libraries.

Your choice of X toolkit will be connected to your choice of language bindings in two ways: first, because some languages ship with a binding to a preferred toolkit, and second because some toolkits only have bindings to a limited set of development languages.

The once-ubiquitous Motif toolkit is effectively dead for new development. It couldn't keep up with the newer toolkits distributed without license fees or restrictions. These attracted more developer effort until they surged past closed-source toolkits in capability and features; nowadays, the competition is all in open source.

The original open-source X toolkit is also moribund. The Xaw library, often known as the Athena toolkit after the MIT research project that spawned X, was written in the mid-1980s as a testbed for the server's features. It supported crude line-drawn widgets resembling those of the original 1973 Alto GUI. We mention it here mainly because you will occasionally run across references to it in the X documentation, but there is no new development in it.

The four toolkits to consider seriously in 2004 are Tk, GTK, Qt, and wxWidgets[19], with GTK and Qt being the clear front runners. All four have ports on MacOS and Windows, so any choice will give you the capability to do cross-platform development.

The Tk toolkit is the oldest of the four and has the advantage of incumbency; it's native in Tcl and bindings to it are shipped with the stock version of Python. Libraries to provide language bindings to Tk are generally available for C and C++. Unfortunately, Tk also shows its age in that its standard widget set is both limited and rather ugly. On the other hand, the Tk Canvas widget has capabilities that other toolkits still match only with difficulty.

GTK began life as a replacement for Motif, and was invented to support the GIMP. It is now the preferred toolkit of the GNOME project and is used by hundreds of GNOME applications. The native API is C; bindings are available for C++, Perl, and Python, but do not ship with the stock language distributions. It's the only one of these four with a native C binding.

Qt is a toolkit associated with the KDE project. It is natively a C++ library; bindings are available for Python and Perl but do not ship with the stock interpreters. Qt has a reputation for having the best-designed and most expressive API of these four, but adoption was initially hindered by controversy over early versions of the Qt license and was further slowed down by the fact that a C binding was slow in coming.

wxWidgets is also natively C++ with bindings available in Perl and Python. The wxWidgets developers emphasize their support for cross-platform development heavily and appear to regard it as the main selling point of the toolkit. Another selling point is that wxWidgets is actually a wrapper around the native (GTK, Windows, and MacOS 9) widgets on each platform, so applications written using it retain a native look and feel.

As of mid-2004 few detailed comparisons have been written, but a Web search for “X toolkit comparison” may turn up some useful hits. Table 3.1, “Summary of X Toolkits.” summarizes the state of play.

Table 3.1. Summary of X Toolkits.

ToolkitNative languageShipped withBindings
TkTclTcl, PythonYYYYY

Architecturally, these libraries are all written at about the same abstraction level. GTK and Qt use a slot-and-signal apparatus for event-handling so similar that ports between them have been reported to be almost trivial. Your choice among them will probably be conditioned more by the availability of bindings to your chosen development language than anything else.

[19] wxWidgets was formerly called wxWindows; the name was changed to avoid a lawsuit from Microsoft.