One of the nice things about running Microsoft Windows is that all your applications look and feel the same. You know that there will be a bar at the top of the window with some pull-down menus, that Alt-F4 will quit, Ctrl-X will cut, Ctrl-V will paste, and so on. Even with a brand new piece of software, everything looks familiar, and you don't have to spend time getting used to a new user interface before you can start to use the application.

Compare this with the X world, where it seems that no two applications look the same, and you often have to spend a few minutes familiarizing yourself with the controls, even with programs you have used before. Why is there such a difference in the appearance of X applications, when it could be argued that the Graphical User Interface (GUI) of a program is one of its most important parts?

The most basic tool for X programmers is Xlib, the X programmer library. It effectively hides the details of the X protocol from the programmer in a library of C subroutines. However, Xlib routines are very low level. The idea behind Xlib is to give the programmer a convenient environment while offering the full flexibility of the X window system. In particular, the programmer has to implement his/her own user interface. There are two important consequences of this. Firstly, there is a lot of work for the programmer, since common components such as scrollbars, buttons, etc. have to be written from scratch. Secondly, it means that different applications look and feel very different, since programmers implement their own GUIs according to their own personal taste.

The designers of X addressed the first problem by providing Xt, the X Window toolkit. This provides a set of functions that handle the user interface and other X-related sections of an application program, such as window creation and event handling. Xt provides routines at a higher level than Xlib, making life easier for the programmer. Although Xt is written in C, it has an object-orientated approach to the problem. The functions in Xt appear as self contained program units called widgets. Widgets are arranged in classes, and each widget class performs one particular type of task. Some widget classes provide the on-screen GUI components (scroll bars, buttons etc.), while others assist with managing the overall layout of the GUI. For example, the HTML interpreter of NCSA Mosaic is implemented as a (very complicated) widget.

Xt consists of two layers, the Intrinsics layer which provides an environment in which widgets can be created and managed, and the widgets themselves, which are usually packaged as a widget library. Several widget libraries exist, the most commonplace being the Athena widget library, which is provided as a part of X as an example widget set. The Athena widget library has been widely used, especially in public domain software, because it is widely available and free. Unfortunately, it consists of only a few basic widgets, which are often considered to be quite ugly.

A well developed and popular widget set is provided by the Open Systems Foundation as part of OSF/Motif. Motif provides literally hundreds of widgets, and is used in a lot of X application software. The recent cross-vendor COSE agreement describes a GUI style which is heavily based on Motif. One possible consequence of this agreement is that we could start to see X applications with a consistent look and feel, even though they are running on different hardware with different operating systems. This would help shake off some of the antipathy that is directed at the X window system.

There is a danger that all this could pass the Linux community by. Motif is typically bundled with commercial Unix/X systems, but since it is a commercial product, it does not come as part of XFree86. Several versions of Motif are available for Linux users, retailing in the region of $100—$200, but it is probably fair to say that most Linux users are quite happy to do without Motif, rather than pay for it. After all, we have a free operating system, a free C compiler, a free DOS emulator, a free windowing system, and so on. $100 for Motif? No, thanks.

However, Motif is already the de facto standard in the rest of the Unix world, and the reliance on Motif is likely to increase with the COSE agreement. While it is possible (depending on their licensing arrangements) for vendors to distribute statically compiled binaries of applications that use Motif, it would be preferable for everyone to have their own copy of the library. It is highly unlikely that the OSF is going to make Motif available free to Linux users, but this is where LessTif comes in.

LessTif is an active project of a group called the Hungry Programmers. It is intended to be a free widget set with exactly the same look and feel as the Motif library. More importantly, it will be source code compatible with Motif, so that the same source will compile with both libraries and work exactly the same. At the time of writing, the current focus is on getting the functionality of the Motif 1.2 widgets. When that is done, the intention is to add some of the features of Motif 2.0, and possibly other extensions. The speed of development of the code is quite astonishing. New releases are made weekly, and there is an active mailing list where patches and improvements are sent in the meantime. The main developer of LessTif is Chris Toshok of the Hungry Programmers, but many others are contributing to the project, and new contributors and bug reports are welcome.

The developers of LessTif are working only from descriptions of Motif 1.2 available in books and header files—they have no access to the “real” Motif source. Some of the developers have Motif libraries, so they cay compile applications against both libraries and compare the results. At the time of writing, LessTif still is at alpha status—we are still a long way from being able to compile and run most Motif applications using LessTif. There is a list of programs known to compile, link, and run with LessTif, but it is quite short at the moment. Other programs compile and link, but are still a long way from being usable. It is unrealistic to expect the developers to be able to give firm release dates, since for most (all?) of them, LessTif is a spare time project, but the developers hope that a usable release will be available in the reasonably near future; perhaps even this year. It looks very likely that the LessTif project will eventually succeed in its aims, and that Linux users will have access to a free Motif-like library.

The combination of the Xt toolkit with a suitable widget set still only addresses part of the problem. It provides the programmer with the building blocks for a user interface, but the responsibility for actually constructing the interface still lies with the developers of each individual application. In recent years, users have come to expect many features from their programs, such as context-sensitive on-line help, drag-and-drop facilities, and inter-application communication—and they expect to see them work the same way between different applications.

While there are guidelines for constructing such high-level elements, such as the OSF/Motif style guide, these guidelines are often written without consideration of the tools available to the programmer. Without a suitable set of tools with which to work, each developer will inevitably interpret the guidelines differently as they implement a user interface from the lower level building blocks provided by Xt and a widget library. Another factor is that the widget set being used may pre-date the style guidelines the programmer is attempting to follow, so that the widgets available may not be suited to the tasks at hand. What is needed, then, is a still higher-level toolkit which is tailored to the specific task of providing a GUI, and which enables the programmer to provide the features the user expects in a consistent fashion. These higher level objects are known as application frameworks.

Application frameworks have been used successfully on Macintosh and Windows systems, which is why there is such similarity between applications in each of those environments. Until recently, application frameworks have not been common in Unix environments, but that is beginning to change.

Silicon Graphics provides an application framework called the IRIS ViewKit (TM) with their workstations. The ViewKit is not intended to be a stand-alone library, but instead is meant to be used in combination with the Motif library. This gives software developers the ease, power, and consistency of the higher level objects, but allows them the full low-level flexibilty of the Motif widgets should they need it. This approach helps avoid the main danger of application frameworks—that the desired behaviour of the application has to be compromised in order to work within the framework.

As workstation vendors provide these application frameworks, the gap between the Unix environments and the personal computer environments should begin to narrow. Again, there is a danger that Linux will become the poor relation of the Unix world.

The Hungry Programmers are also busy attempting to ameliorate this problem by developing a free application framework which can be used on Linux. Called the Hungry ViewKit, it is a C++ class library for developing Motif applications which follows the API of the IRIS ViewKit. It is intended to be a superset of the Silicon Graphics kit, so that all code developed for the IRIS version will work will the Hungry kit, but not necessarily vice versa.

The LessTif project is in fact a spin-off from the development of the Hungry ViewKit. While working on the Hungry ViewKit and XWord (a word processor being developed for the X window system) the Hungry Programmers felt that there was too much reliance on the Motif widget set, and decided that they should implement a look- and feel-alike.

At the moment, there is no documentation available for the Hungry ViewKit, but the XWord source is available as an example of its use. Work on XWord has been given a higher priority than fixing bugs on the ViewKit. Thus, while a release of the Hungry ViewKit is available, it is not yet for the faint-hearted.

[Author's Note: As is the nature of the Web, the URLs I gave in the original article have changed. I believe the revised URLs below are correct.]

The Hungry Programmers have a home page, at https://www.hungry.com:8000/ or can be emailed as hungry@uidaho.edu. The LessTif home page is at https://www.hungry.com:8000/products/lesstif/ and you can subscribe to the LessTif mailing list by e-mailing majordomo@hungry.com with the request subscribe lesstif in the body of the message. Alternatively, the request subscribe lesstif-digest to the same address gets you the list in digest form. There is also a LessTif documentation project at the URL https://www.hungry.com:8000/products/lesstif/Lessdox/ The Hungry ViewKit home page is at www.hungry.com:8000/products/viewkit