In addition, these operating systems provide at least an abstraction from the basic hardware layers in form of a windowing system API (or abstract text terminals for less sophisticated interfaces). However, user interfaces programmed along these APIs are not portable to other operating systems. Portability can be achieved by building on a higher layer of abstraction, the client-server interface. The most prominent example is X-Windows ([2]). The X-Windows server controls one or more hardware interfaces consisting of screen, keyboard and various pointing devices. A large set of window operations and drawing operations within windows is provided. Events like keys being pressed or the mouse being moved are communicated back to the client (application and user-interface). X-Windows allows server and client to reside on different machines and communicate over a network which is extremely important for environments with several different computer architectures. The more, many tasks like distributing events to widgets (parts of a user-interface like a single button) are simplified.
X-Windows servers are available on almost any UNIX clone. In addition, there are many commercial servers for Windows 95 and Windows NT that build on the Windows APIs. Thus, building interfaces based on X-Windows guarantees portability across the most important computer platforms. There is no real need to base user interfaces on platform-dependent APIs any more except for operating system services like printing or network communication, let alone write special purpose hardware drivers for particular devices.
Another successful paradigm is notification-based programming. The parts
of the interface register callback functions. A notifier function
receives input events and calls those callback function that match the
event. Selecting callback functions can be based on
An important design model for user interface implementation is the
application-control-interface model that appears in various flavors
throughout the HCI literature. This model separates the user interface
strictly from the application. Keeping up this separation in the
interface implementation has several advantages:
The graphical interface provides
basic editor functions without requiring a lot of user training. The
Lisp interface is more powerful in cases where a complex, custom
operation has to be performed on a text.
A large part of higher-level Emacs
functionality is implemented in Lisp. Lisp is certainly not the language for
allowing non-expert users to extend a user interface, but the fact
cannot be denied that the simplicity of the Lisp interface has allowed
many programmers to contribute to Emacs by writing own custom Lisp programs
for particular purposes (e.g. programming, reading mail, viewing HTML
files, ...).
The Emacs example can be easily extended to other applications. For
example, in my opinion vector graphics drawing is very well suited for
combining a graphical interface with a powerful programming language
(here, a functional and object-oriented language would be
appropriate). The programming facilities could be used to support fast
creation of complex drawing while the user interface can be used for
simple drawings and also for convenient input of point positions to
the programming engine.
Other important advantages of interface-application-separation are
Abstraction primitives
The wealth of primitives the X-Windows system or the various Windows
APIs provide for user interface programming are not without
alternatives. Parts of them have been criticized for their complexity and lack of
flexibility. For drawing operations, PostScript
is an interesting alternative. PostScript is a full-fledged
stack-oriented programming language (derived from Forth)
originally developed by Adobe as the basis for a portable
document format for high-quality printers.
The screen is modeled as a set of infinitely thin contours
that surround areas filled with various colors or patterns. Fonts and
text are described in this way as well as images and
drawing. PostScript is renowned for its simplicity. It was adapted for
the NextStep
operating system's graphics API. Extensions exist for combining input
primitives. PostScript based interfaces might be used more widely in
the future.
User interface programming paradigms
Many user interfaces belong to the input-action-output loop
category. This paradigm is very common for command-line interfaces,
but occurs also in GUIs. Apart from its simplicity, it has some
disadvantages. It is not very well suited for user interfaces that
support various degrees of multithreading. In addition, much code has
to be written in order to properly distribute input events to various
parts of the interface.
One of the drawbacks of notification-based architectures is that they
do not enforce a clear hierarchical structure by themselves and therefore
require more careful program design. In addition, input-action-output
architectures support the concept of interface modes more
readily. For example, an interface could switch to error mode if an
error conditionoccurs in the application. In error mode, the set of
actions available to the user might be radically different from the
previous mode. Notification-driven architectures require a lot of
callback function dis- and enabling while input-action-output programs
simply change to another loop.
There are many examples of systems that were developed with respect to this
paradigm and its benefits. One example is the Emacs editor available
for the UNIX operating system. Lower levels of Emacs are implemented
in C (most likely, for speed and convenience reasons). Emacs contains
a Lisp interpreter and exports a set of editor operations as Lisp
functions. Apart from this Lisp interface, Emacs also provides a
standard graphical user interface.
Programming languages
Choosing the programming languages for an interface implementation is
an important decision. User interfaces are unusual software objects:
Time and space efficiency have relatively low priority. This allows
for using interpreter languages instead of compiler
languages. Some advantages of interpreter languages:
Apart from Emacs Lisp described above, another important example of a
GUI programmed with an interpreted language are
the Tcl script language and the Tk toolkit (see below).
User interface programming is a stronghold of both compiled and interpreted object-oriented languages. This is due to the fact that inheritance and polymorphism occur naturally in many aspects of user interfaces. As an example for inheritance, consider a class of buttons with label text, derived from a class of mere buttons, derived from a class of invisible screen-coordinate rectangles that receive all input events that occurred when the mouse pointed into them. The most prominent example for polymorphism are the event handling methods of objects (which correspond to the callback functions described above). All the notifier has to know is a reference to the event handling method. Each class of interface objects provides its own implementation of this method. Obviously, object-oriented languages provide for a tremendous degree of code reuse. A closer look at most toolkits based on non-object-oriented languages like C (e.g. Motif) reveals that they use some object-oriented ideas, too, in a less explicit manner.
Important examples of object-oriented languages used in user-interface design are
An interesting example is the Tk toolkit with its many extensions. I will describe only a subset of its many characteristic, important features in order to give an idea of the support toolkits can give in interface programming. Tk and the script language Tcl were designed by John K. Ousterhout (Sun Microsystems, formerly University of California at Berkeley). The Tk toolkit itself is programmed in C, building on X-Windows and alternatively Windows APIs. Thus Tk-based interfaces have the important property of portability.
Tk provides a set of Tcl functions that allow for fast design of user interfaces. (The Tk toolkit has also been adapted for programming using various Lisp dialects like Scheme because many people felt that, from a software engineering point of view, Tcl did not provide enough support for structured and modular programming).

When programmed in Tcl, Tk allows for binding arbitrary Tcl functions to various X-Windows events. The events can be selected by type, parameters and target widget. Example:
bind .listboxWhen the user presses the left mouse button over the Listbox{ user_selected_beverage [.listbox get curselection] }
.listbox, a handler function (defined in between
{}). This is a striking example of the simplicity of
programming notification-based interface architectures.The third and last feature I am presenting here is the Xf tool. Xf (which, with due respect to its beta version status, is not an example of good interface design) provides functionality common to many user interface development systems: the programmer can layout the application in a WYSIWYG manner rather than cycling in the usual slow programming-testing loop.
![]() | ![]() |
Xf: configuring the packer parameters for a scrollbar