`Look and Feel' Part 1 - Toolkits for Application Programs
The `look' of a program is its visual appearance - how the various controls are laid out, what the components such as menus, scrollbars, buttons and so on look like, and the overall style.
The `feel' of a program is how it behaves - how the scrollbars operate (can you drag them with the mouse, what happens when you click in certain areas with the left mouse button, with the right?), whether you can `press' pushbuttons by hitting the keyboard's space-bar or return key instead of clicking with the mouse, etc.
It is the combination of the look and the feel that makes up the overall user interface. It is not only windowed computer programs that have a look and feel: other programs, especially DOS PC applications such as spreadsheets or word-processing packages, have their own recognizable and distinctive look and feel. [Footnote: The distinctiveness of a system's look and feel is the basis for the recent vogue of lawsuits alleging infringement of copyright or other intellectual property rights.] Computer keyboards have a look and feel. Keys are labelled `QWERTY. . . ' along the top row, `ASDFGH. . . ' along the middle row, etc., and that is the look; when you press the key marked F, say, you get the character `f' printed, and that is the feel.
Even the controls of a motor car have a look and feel: the look for a car with manual transmission is shown schematically in Figure A. This is quite a good example of why you want look and feel to remain consistent even in products from different manufacturers, and how nasty it can be if they don't. For instance, you expect that a car's accelerator (gas) pedal is on the right, and the brake pedal is to its left. What would happen if Volkswagen used that convention, but Ford decided to use the opposite? How easy would it be to drive a car of the other type - a car which has the same look (two pedals) but a different feel (the pedals have opposite `meanings')?
So, while look and feel is a general term, it is increasingly used to mean consistent appearance and style of operation. In the next module we list what we require of look and feel for applications.
What we want from the look and feel of an application is
In fact most of these are user demands. Vendors have not automatically provided these features, but they are now being forced to listen to what their customers want, to remain competitive.
In the next modules we'll see that X lets developers build many, very different, look and feels. We'll look at what they are like, and how they are implemented.
As we described in Module 1.2, the look and feel of an X program is not part of the base system - it is not determined by the server, but is part of the individual application. So, it is possible that each application can have its own distinct look and feel! In the old days, this is more or less what happened: each applications programmer or group of programmers wrote their own. This was bad for users, first, because the user ended up with many different and inconsistent look and feels, and second, because programmers are not necessarily good user interface developers, and some of the look and feels produced were very bad indeed.
However, not building a standard interface into the system does have its advantages. New developments and advances are possible; as the user interface is part of the applications program, researchers have complete freedom to alter it and experiment with new ways of working. This is not possible with most other systems. The source code of X is freely available, which also makes X the obvious choice for experimentation, in the same way that UNIX has often formed the basis for operating system R & D.
Not specifying a look and feel also means that X systems can provide a user interface that is compatible with some other system. For example, Motif is very similar to Presentation Manager and the interface available on Microsoft Windows. It would also be possible to duplicate the interface of the Macintosh (but you would need good lawyers to defend you in case of a law suit from Apple).
This freedom of development leads to an organic evolution of the system. Many new interfaces or look and feels are produced, the best of which form the springboard for future work, leading eventually to the adoption of the best technologies as de facto standards. Ideally this occurs only after the technology has matured enough for a really good system to be available.
Unfortunately, there are disadvantages too. Several viable look and feels have emerged, and each vendor is trying to make their own one the single universal `standard', resulting in the `GUI wars'. In practice, we end up with multiple standards, which means confusion for users, and extra work for developers who have to work with all the different systems. (For example, Figure A shows some of the variants of scrollbar offered by different user interfaces.) This diversity is paradoxically a result of the need for the large commercial software marketplace to have a standard; the demand is so great that some common look and feel needs to be defined now, even though it may be premature, and that there just has not been enough time or work done to give the richness of choice necessary before some single interface is chosen and cast in stone. But the user community is demanding standards, so standards are being provided.
In the next module we look at some of these emerging standards.
MIT provide a sample implementation of a look and feel, with their Athena toolkit. This is a relatively simple and unsophisticated system, but it does provide a model for other developers. It is used only in sample applications provided by MIT and in very few other cases. An example of an application using this look and feel is shown in Figure A.
Both Motif and OPEN LOOK have a 3-D appearance, and they offer more or less similar functionality. However, they differ in visual detail, as you can see from the Figures. They also differ in the way the user interacts with them, particularly as to the extent to which you can control an application using the keyboard instead of the mouse. Also, OPEN LOOK provides drag and drop facilities, and a push pin to force pop-up menus to stay popped up (Module 8.3); also, a full implementation comes with a file manager application, which provides many of the facilities required from a desktop manager (as described in Module 9.6).
In the next module we discuss how X can have so many different user interfaces, and not insist on a single standard.
For now, many people hedge their bets and use both standards, perhaps helped by a toolkit which allows you to develop applications capable of providing either look and feel (see Module 7.5).
A user interface toolkit (or just a toolkit) in X usually provides a set of user interface components from which the applications programmer can assemble the user interface, that is, a set of ready-made building blocks. Figure A shows that the user interface code is actually contained in the application, and also that the toolkit provides a higher-level programming interface.
It was always intended by the designers of X that applications would be written with a toolkit. Writing an application using a toolkit rather than basic Xlib functions is analogous to using a high-level language instead of assembler, or writing a C program using the Stdio I/O library instead of raw operating system calls. Initially programs were written using only Xlib; toolkits are a later development, and represent a maturing of the technology, overcoming many of the earlier problems and simplifying the programming task.
The toolkit provides the applications programmer with a set of ready-made user interface components, which are used in different ways to build up the complete user interface, in much the same way that a house is built from pre-manufactured components such as bricks, doors, electrical sockets, etc. The toolkit also contains the functions necessary for creating, assembling and managing these software components.
By using the standard components we get a consistency within all applications built with that particular toolkit, whether they are written in-house or are bought in from an independent vendor, and irrespective of which platform the application has been written for. So, Motif applications running on a DEC VAX are look and feel consistent with Motif applications running on a Sun; you can't tell them apart. (However, the fact that two applications have the same look and feel does not mean that they were built with the same toolkit. Remember, look and feel defines how the application appears to the user. The same external behaviour in a program could be provided in several different ways internally. For example, you could have three functionally similar programs, written respectively in C, Lisp, and Ada, with each using a toolkit written in its own language.)
Toolkits usually also provide special functions for tasks related to the user interface. For example, to use an application principally via the keyboard and minimize the need for the mouse, we need special keyboard handling to replace normal mouse functions. We want to be able to define mnemonics - special key sequences - so that we can pull down menus and select one of the menu options using only the keyboard. We would also like accelerators or short-cut keys to let us invoke frequently-used menu options directly without having to call down the menu, move to the option, and select it explicitly. (For example, in a word processing system you want to be able to save the document easily. Often ctl-s is used as an accelerator for this, that is, as a quick way to invoke the Save function.) Additionally, for form-based applications we need a mechanism to let us navigate from one field to another. Toolkits often provide these mechanisms.
There are many toolkits available. Some are standard (for instance, the MIT X toolkit, Xt, described in the next chapter) with provision for enhancements or for building your own user interface components using the existing pieces or even starting from scratch just using the framework the toolkit provides. Others are specialist toolkits for particular purposes: for example, a basic graphics toolkit for students starting with graphics programming, or advanced toolkits purpose-designed for CAD and CAE systems. There are language-specific toolkits: for example, to allow X programming in Lisp or Ada. (And you can even write your own toolkit if you have a particular need: for example, to address the problem domain that your organization specializes in, but this is a little extneme!) Module 7.6 deals with other toolkits.
Many toolkits also provide high-level functions to simplify programming; these are covered in the next module.
Using a toolkit also provides high-level functions that are not addressed by the basic Xlib library. For example, X is a pixel-oriented system: all dimensions are expressed in numbers of pixels on the screen, so the physical length of a line will depend on the resolution of your screen. Some toolkits let you express dimensions in inches or centimetres, and convert to pixels internally, so you can write resolution-independent programs. (If you don't use some system like this, or go to a lot of trouble to provide similar functionality yourself, when you produce an application which looks fine on a low-resolution PC screen, then as soon as you run it on a very high-resolution screen it will be about the size of a postage stamp - see Figure A.) Resolution-independence can be particularly important in DTP applications; the text displayed on the screen must accurately represent what will be output on the printer, even though the resolutions of screen and printer are likely to be very different. To give the necessary control over appearance, some toolkits process individually each character to be drawn, computing its size and optimal screen position, rather than relying on the standard X text drawing mechanisms.
Usually a toolkit will handle many routine but essential tasks in an X program. Most components of the user interface, such as pushbuttons, labels, scrollbars, menus, etc. will have been created using the toolkit, and therefore the toolkit can redraw them whenever they have been obscured and re-exposed. In other words, the toolkit can automatically handle expose events for most of its components, saving a lot of tedium for the programmer. Similarly, input event handling can be greatly simplified; for example, pushbuttons can be `pne-programmed' so that they automatically handle mouse
Other functions provided by toolkits include: In the next chapter we look at the standard X way for providing a toolkit, and Module 7.3.1 outlines the extra functionality it includes.
Figure A. Different screen resolutions affect the size of an image on screen.
Summary
In this chapter we have see that the look and feel of X applications - the interface they present to the user - is implemented within the application itself and is not determined by the X server. As a consequence, X can support different look and feels or graphical user interfaces. We considered what people want from a GUI, to make applications easier to use but also to give consistency of usage across all the user's applications. Then we looked at the de facto standard GUIs, Motif and OPEN LOOK. Finally we saw that the user interface in general and GUIs in particular are almost always implemented by means of toolkits. In the next chapter we examine this in depth, concentrating especially on the mechanisms X includes for supporting toolkits.