17.1 A BRIEF HISTORY OF GUI TOOLKITS

17.1 A BRIEF HISTORY OF GUI TOOLKITS

It is probably not far from the truth that modern GUI programming for graphical workstations started with X in the mid-eighties. The X window system gave us a network-transparent method of working on remote computers through virtual terminals on workstations. Using X, the interaction with the remote machine is such that it appears to run locally. The remote machine presents its output in an X window and accepts keystrokes and other user interactions made available through the window. Although X was developed originally for Unix environments, it's now available for practically all the other operating systems.

Although X was without doubt an enormous development in its own right, the support it contains for GUI programming consists essentially of low-level function calls for drawing lines and rectangles, for setting foreground and background colors, and for having events, such as those produced by a mouse, reported back to you. It does not provide facilities for direct creation of what we now take for granted in modern GUI design- buttons, scrollbars, dialog boxes, pop-ups, toolbars, tabbed pages, and so on. The first X-based GUI toolkit that facilitated high-level programming of these graphical components was Motif, which is a combination of both a toolkit and a GUI design specification. Motif makes calls to a lower-level toolkit called Xt (for X toolkit) that sits on top of Xlib, the X library. Xlib is the lowest-level programming API (Application Programming Interface) for working with X. Xt, which was one of the first large software systems to simulate object-orientation directly in C, allows one to create a graphical object, such as a window, but does not require that the window object come with a title bar and have a certain "look-and-feel" to it. The "look-and-feel." specification was supplied by Motif and is now known as the Motif "look-and-feel." The modern Common Desktop Environment (CDE) that ships with most Unix workstations is based on Motif.

While Motif was gaining steam within Unix circles, Win32 API was introduced by Microsoft for PC's. Although the main goal of Win32 API differed from Motif's goal of performing network-transparent computing through virtual terminals on graphics-enabled machines, they both provided the basic programming tools for creating graphical interfaces that users could interact with either by mouse clicking or through keystrokes. But as demands arose for creating more and more sophisticated user interfaces, programmers found it cumbersome to work with Motif and Win32. Programs written using these API's were often error-prone and difficult to debug. Additionally, and perhaps even more importantly, using either Motif or Win32 API's directly meant that a programmer had to spend far too much time on getting the GUI syntax and program-flow to work correctly in relation to the time required for the programming of the core functionality of an application.

Thus there arose a need for even higher-level toolkits that could hide bothersome details concerning layout management, event processing, multithreading, and the like. This need was also fueled by a desire for toolkits that would be portable across diverse platforms. The higher-level toolkits that have come into existence during the last few years include Java-based AWT and Swing, C++-based Qt, C-based GTK+, C++-based wx Windows, also C++-based MFC (Microsoft Foundation Classes), and many others.

While going through the different GUI toolkits in this chapter, the reader should bear in the mind the fact that a high-level toolkit of the kind we present in this chapter often sits on top of a more native GUI toolkit. It can also happen that a high-level toolkit may sit on top of a "tower" of toolkits. The chaining of toolkits in a tower of API's sometimes creates robustness problems caused by the not well-understood and undocumented incompatibilities between the API's. But, more importantly, what visual effects can be achieved with the topmost API become dependent on the capabilities of the API's underneath.

For example, if a high-level API has to call on Motif to process its GUI widget construction code, the final look-and-feel will correspond to Motif. On the other hand, if a high-level API reaches directly into Xlib or directly into the operating system, it could generate its own look-and-feel. Figure 17.1 should give the reader a sense of this aspect of what we will be studying in the rest of the chapter. The high-level GUI toolkits of importance to us that are mentioned in this figure are Swing, AWT, GTK+, and Qt.

Figure 17.1

Figure 17.1 also includes GNOME and KDE, both desktop environments based on the GUI toolkits listed underneath them. But since, while working with GTK+, it is common to include some of GNOME'S functionality, we will refer to both of them as GNOME/GTK+. A paired up name, AWT/Swing, will also be used for the Swing and AWT toolkits since a modern GUI program in Java will include both Swing and and AWT classes.

Note that Figure 17.1 is only approximately correct, in the sense that it shows only the dominant dependencies. For example, Java Swing, while reaching directly into the operating system for most of its GUI construction, depends on Win32 and Xlib for some of its functionality. However, by contrast, Java AWT gets all its work done through calls to the native GUI API's, which is Motif for Unix-like platforms and Win32 for Windows platforms. So the look-and-feel generated by Java AWT (if used without Swing) would correspond strictly to Motif on Unix-like workstations and to Win32 on Windows platforms.

As Figure 17.1 shows, the C-based GNOME/GTK+ system sits on top of GDK, which makes calls to Xlib. (Section 17.3 describes what the acronyms GNOME, GTK, GDK, and so on, stand for.) The C++-based Qt system comes in two versions. The version that works for Unix-like platforms makes calls to Xlib and the version that works for Windows platforms makes calls to the Win32 API.