User Interface Libraries

Several applications use a graphical user interface. Numerous sophisticated tools and libraries exist for constructing user interfaces. While these libraries differ significantly, the underlying functionality is often divided into a number of layers to make it more manageable.

At the lowest level is the display hardware. Display adapters (graphics card) greatly vary in how they are programmed, their resolution, capability and performance. At the top level is the user interface description in terms of buttons, menus, interactors, text and graphics editors and similar meaningful high level constructs.

Device independence

A layer on top of the display hardware is used to abstract the device specifics in terms of functions and capabilities found on most adapters. This layer offers conventional bit block transfer operations and primitive graphics operations. It may be queried for the resolution and the number of bits per pixel. It may also manage the input devices (mouse and keyboard). A good example is the Sun Pixrect library.

Given the very large number of different display adapters, it is essential to isolate these differences in a library such that the rest of the functionality can be developed independently of the hardware.

Low level graphics

A second layer can be used to offer the primitive building blocks such as rectangles, polygons, fonts and text, overlapping windows and input management. Indeed, this functionality is needed in almost all applications. The X windows server and the associated X library operates at this level.

Some systems go further and offer resolution independent graphics operations with transformation matrices, scalable fonts and filled regions in real units (e.g. millimeters) instead of pixels. The now defunct Sun Network Extensible Windowing System offered such functionality. Display Postscript also operates at this level.

Building blocks for toolkits

The next level is to provide building blocks for higher level constructs. This may include horizontal or vertical stacking of elements, overlaying elements and similar constructs to build menus, frames, drop shadows... These elements form a tree. The root is the window, the leaves are the primitive elements such as text or rectangles and the internal nodes are groupings such as piles or overlays.

When an element changes appearance, it must send paint operations to its father in the tree. The father may clip or translate these paint operations before sending them up in the tree. When an element changes size, it notifies its father which may decide to re divide its available screen estate among the childs or ask its own father for more (or less) space. Similarly, when the window shape is modified by the user, the space allocated to each node in the tree may be modified. If the window is moved or part of its content erased by another window, the elements in the tree associated with the damaged region will be asked to send their paint operations.

Mouse events (moves or clicks) are also propagated along the tree. A father will normally determine in which of its childs the mouse cursor is located and relay the mouse event to that child.

This well structured organization is mostly found in object oriented libraries built on top of X windows. Interviews in C++, or its successor Fresco, and Trestle in Modula-3 are prime examples.

Toolkits

There is an important shift between this layer and the previous ones. Indeed, lower layers are tightly bound to the screen appearance while toolkit elements correspond to conceptual elements presented or queried from the user such as choices, file names, texts...

It is interesting to note that the basic elements offered by most toolkits do not vary much: menus, buttons, check boxes, file choosers, text and graphics editors. Their appearance, however, varies widely in small details such as key bindings, mouse actions, colors, 3D look with drop shadows, default fonts...

Such toolkits include Motif, the higher level portion of Interviews, and VBTkit. A number of toolkits make the same application programming interface available on a number of different platforms (X windows, MS Windows, MacIntosh...) and appearance (Open Look or Motif look and feel). This way, application developers using such a toolkit can, with the appropriate version of the toolkit, get their application running on several platforms without change.

Graphical interface builders

Sometimes, tools are available above the toolkit layer. A graphical editor may be used to position the user interface components by direct manipulation (graphical interface builder). However, complex relationships are often easier to represent in a programming language than through direct manipulation. Indeed, positioning a file chooser at pixel 230 within a 500 pixels wide window is different from specifying that the file chooser must be centered within the window.

A graphical interface builder may produce source code calling the toolkit. This code must be compiled and linked with the application. Some interface builders produce an interface description that is read by the application at run time. A small performance penalty is paid to interpret the interface description but this enables changing the user interface without recompiling the application. The FormsVBT interface builder produces such run time descriptions.

User interface and Object Orientation

User interfaces are obviously distinct from object orientation but they are often mentioned in books on object oriented programming, if not used as examples. Similarly, the father of the modern object oriented languages, Smalltalk, was mostly used in the context of graphical programs.

Indeed, user interfaces and the underlying layers are an excellent example of object oriented applications. Before C++ became popular, the Pixrect library used a function table to describe each device. The first function in the table would initialize the corresponding device, the second would copy a bitmap and so on; this is nothing else than a method table.

Each element, in the graphics tree associated with a window, must negotiate with its childs to allocate the available screen space. The childs may be of different types but must all support the space allocation negotiation, common to all graphics tree elements; this is easily achieved with inheritance and methods.

At the toolkit level, many different interactors (widgets) may be used to query a character string (file chooser, menu, type-in, editor). In each case, a method called getText may be used to obtain the string.

Finally, many user interfaces claim to be object oriented, irrespective of their underlying implementation. They often mean that a small set of actions is applicable to all graphical elements (select, move, resize, delete, change property).


Copyright 1995 Michel Dagenais, dagenais@vlsi.polymtl.ca, Wed Mar 8 14:41:03 EST 1995