Print
Close Window
From: www.itworld.com
GTK+ matures
March 29, 2001 —
GTK+ is an acronym for the GNU image manipulation project (GIMP) toolkit. Spencer Kimball and Peter Mattis began work on GIMP in the summer of 1995. The first versions of GIMP relied on Motif, which was the dominant commercial standard for Unix GUI development over the last decade, as we explained in an earlier report in this series on GUI toolkits.
However, Kimball and Mattis wanted GIMP to be entirely free, and Motif's license was quite restrictive at the time. They decided to recraft GIMP as a free, general-purpose GUI toolkit, the first version of which they released as GTK in July 1996.
So one of GTK+'s distinctions has always been its license. It's a solid member of the GNU project, available under the GNU Lesser General Public License (LGPL). This may be the feature that developers mention most often when explaining their choice of GTK+. Many programmers now actively seek out licenses such as LGPL, instead of Motif or other toolkits.
The force of the license argument has diminished since GTK+'s birth. Qt's license has been liberalized, and Motif's source code is now available in some situations. There are even a few situations -- mostly concerning Linux-based embedded systems -- where the GTK+ license is inconvenient for proprietary-software developers. It is more common, though, for an organization to prefer Motif or Qt because of their restrictive commercial licenses.
GTK+ speaks in many tongues
One of GTK+'s primary features is good support of different languages. While GTK+ and Qt share many technical characteristics, Qt is coded in C++, and well-maintained bindings are only available for C++ and Python. By contrast, "GTK+ is written in C, and has from the very beginning targeted bindings to other languages," said Owen Taylor, current co-maintainer of GTK+. Taylor is employed by Red Hat Advanced Development Labs.
Many programmers, especially those coming from Motif or Windows GUI environments, simply want to work in C, making GTK+ a natural choice. For those who prefer other languages, Taylor explains the situation:
Maintaining a GTK+ binding is not a completely trivial task. GTK+'s design makes it really easy to get a simple language binding up and running that covers 90 percent of everything that a programmer wants to do, but to get really thorough coverage of all 1,400 or so entry points to GTK+ takes a fair bit of effort, especially if you want to get a binding that really fits the language well.
Of the 20 or so language bindings out there for GTK+, perhaps half a dozen are really complete and heavily tested; in particular gtk (C++ binding), the Ada bindings, and the Perl and Python bindings come to mind.
... Even the less complete bindings can still be valuable. We're seeing quite a few people looking at using GTK+ with teaching languages as a way of introducing user interfaces. Before GTK+ became common, the standard way of doing this was either to write your own (usually primitive) toolkit, or write wrappers around Tcl/Tk.
Taylor emphasizes the GTK+ development crew's commitment to stability. "Once we finish a stable version ... people can be assured that their language bindings will work across versions."
Potent widgets
The enthusiasm that fuels GTK+'s proliferation of language bindings has also had a hand in the functionality of the core GTK+ widget set. Early releases of GTK+ had rough edges, compared to alternative toolkits. Perhaps most troublesome, the GTK+ documentation lagged behind the libraries in early versions -- users often didn't understand how to exploit the facilities already present. Still, thousands of applications based on 1.0-1.2 have been produced successfully. Moreover, the 2.0 release of GTK+, which Taylor expects by the first quarter of 2001, brings a sense of completeness and coherence to the library. With 2.0, GTK+ speaks Unicode, its textual widgets will properly handle right-to-left scripts, and the tree/list and text widgets are completely rewritten, more powerful, and easier to use.
GTK+ seems to be spawning new generations of projects, which is encouraging for its long-term health. Just as GTK+ began in the service of GIMP, the 2.0 release has generated several standalone libraries, including Pango, which encapsulates all rendering and management of complex human languages. This means the core of GTK+ doesn't need to take responsibility for these issues. Moreover, this partition makes Pango available to other libraries and applications, including those concerning printing.
Even before 2.0's release, GTK+'s widget set had many fans. Theming (selection of a widget display style) is a built-in capability. GTK+'s set of built-in widgets is richer than Motif's, and GTK+'s geometry management is simpler. GTK+ is at least as modern as any widely available Unix toolkit; that is, it offers most of the capabilities and the appearance Windows programmers expect.
Moreover, many extensions have been built on GTK+. The GnomeCanvas widget, for example, has excellent performance and advanced anti-aliasing.
GTK+'s documentation
GTK+'s documentation, like its core functionality, has always had strengths and appears to be maturing nicely. Jonas Munsin, author of the gcombust project, said ease of learning first attracted him to GTK+: "GTK+ had, from the early beginning, quite a good tutorial -- documentation on how to get started was a major advantage of GTK+."
Maintaining that documentation has been a challenge, though. It's much easier to make a basic language binding that accesses most of GTK+ than one that connects to all of it; similarly, even the tutorial has struggled to keep pace with GTK+'s richness. A half-dozen books are now available for GTK+ help. As a long-term solution, Damon Chaplin manages the Reference Documentation Project (RDP). While the RDP has several holes in it, including such important pieces as GtkWidget, GtkContainer, and GdkWindow, Chaplin hopes "that more effort will be put into the documentation once the GTK+ 2.0 code stabilizes."
Although it has no direct impact on the GTK+ documentation, one of the first enhancements Chaplin aims to make is to the gtk-doc automation that generates documents from source code. This will "make gtk-doc easier to set up when used with other libraries," Chaplin said. "It is now used for quite a lot of the GNOME libraries as well as GTK+."
Accessorizing your toolkit
Chaplin also devotes time to Glade, a user interface builder for GTK+ applications. Chaplin wrote most of Glade, which he now maintains. It is a marvelous tool for developing useful GUI applications. Just as some programmers choose Motif for its UIL, or Qt for Qt Designer, Glade's power makes a convincing argument for its underlying toolkit. Glade's interfaces are structured in XML, which creates opportunities to tie together different technical tools, automations, and work processes.
Glade isn't the only bonus GTK+ users enjoy. Powerful extension libraries like gnome-libs make it hard to consider GTK+ as separate from the accessory tools and extensions that have grown up around it. In fact, many GTK+ users don't recognize the distinction between the GTK+ core and all the goodies that surround it.
Fashion and politics on the desktop
That misunderstanding occasionally leads to political contention. Although GTK+ was originally designed for GIMP, one GTK+-based application is now even more famous than GIMP: the GNU Network Object Model Environment (GNOME). GNOME is a leading desktop environment for Linux. In the last few months, most proprietary commercial Unix vendors have miraculously adopted GNOME as a standard instead of CDE.
GNOME is built on GTK+, which demonstrates the toolkit's performance, portability, and power. It also makes GTK+ a natural choice for those in search of Unix desktop standards. However, there's considerable confusion about the relationship of GNOME and GTK+. GNOME, as a desktop, does not require that applications be built with GTK+; nor are GTK+-based programs restricted to the GNOME desktop.
Still, computing incorporates a large fashion component, and recent marketing events have undoubtedly given momentum to GNOME's relatives, including GTK+.
GTK+'s downsides
Why would anyone not choose GTK+ for his or her next project?
There's inertia, of course; other toolkits are as much as a decade older, and thus more trusted. But perhaps the most frequent complaint about GTK+ is its mediocre support of Win32. While GTK+ 2.0 includes a framework that addresses this problem, GTK+'s Windows support hasn't ripened like Qt's and Tk's. A couple of ports to Mac OS of GTK+ have also been started, but seem stalled in a far less usable state than the Win32 GTK+.
On the other hand, the 2.0 framework includes explicit support for interesting variations, such as a Nano-X port, which promises to make GTK+ practical in memory-constrained or very high-performance environments.
GTK+ has historically suffered from inadequate documentation of its memory management. It has been harder to write correct code in GTK+ than in, for example, Qt. Release 2.0 goes a long way toward correcting this.
It will likely still be difficult to keep up with GTK+'s nomenclature. As we mentioned earlier, GTK+ has attracted a large and lively crowd of developers, and it is quite a challenge to grasp the project as a whole. Even the name GTK+ raises enough questions to deserve its own paragraph at its Web home:
I originally wrote gtk, which included the three libraries, libglib, libgdk and libgtk. It featured a flat widget hierarchy. That is, you couldn't derive a new widget from an existing one. And it contained a more standard callback mechanism instead of the signal mechanism now present in gtk+. The + was added to distinguish between the original version of gtk and the new version. You can think of it as being an enhancement to the original gtk that adds object-oriented features.
The status of GTK+'s object orientation remains technically controversial. Some programmers strongly prefer the Qt approach or Motif's component model. The latter has been particularly successful in its design goal of promoting a lively secondary market in utilities and extensions. Many of Motif's most sophisticated users strongly favor this model. However, Taylor said:
I'd say that the GTK+ object model is probably more advanced than the Xt one; it is specifically targeted at working with GUI builders and high-level languages, rather than X resources and the like.
This will be especially true with GTK+ 2.0, which has a number of enhancements in this area ... Object properties have been extended to allow defaults and (for numeric properties) ranges and documentation strings.
Many more objects in the GTK+ universe become GObjects, so not only widgets are objects, but also GdkWindow, PangoLayout, and so forth. This allows much more of GTK+ to be handled from generic code.
Whatever the merits of GTK+'s particular technical details, the toolkit is clearly young and supple enough to digest the best efforts and ideas in the world of GUI toolkits. You owe it to yourself to look into GTK+.
Resources
Unix Insider