Issues for Implementing User Interface Software
Arno Schoedl, Georgia Institute of Technology
There are four main tasks to fulfill in a windowing system: providing graphics hardware abstraction, multiplexing multiple applications on the screen, providing a toolkit for a common look-and-feel of applications and a window manager. Multiplexing multiple applications on the same screen leads to external application input where no longer applications poll for input but they get notified by messages when an appropriate input occurs. Object-oriented and prototype-based programming paradigms offer a much more natural way to program user interfaces than conventional procedure-based languages. Programming interfaces is further simplified by using graphical development environments. User interface management systems are application architectures to provide separation between the interface and the data model of the application.
Most interactive programs today use the WIMP interface paradigm. Two main problems arise, that is the hardware dependence of graphical output and sharing of input and screen resources among multiple running applications. To shield applications from these two problem areas and to factor out common tasks of applications with graphical user interfaces a client-server approach is commonly used. I will to look at both sides, the client and the server, in turn to determine the major issues that influence their implementation and how to deal with them.
1. The Windowing Server
I have identified four main tasks that a windowing system like X11, Windows or MacOS has to perform.
Graphical user interfaces are much more demanding on the hardware than conventional text-based interfaces. It is common that today's computers have some hardware capabilities that accelerate display operations often used in WIMP interfaces, like for scrolling operations, display of icons and graphical text or filling of rectangles. The windowing system has to shield the application from the low-level interface of the graphics hardware. The window server itself normally uses some hardware-dependent device drivers to use the graphical capabilities of the computer, or in case of the Xwindow system for example, a customized server is provided for each underlying graphics hardware.
In a WIMP interface applications are no longer alone in using the output and input devices, and the windowing system has to manage multiple applications by assigning screen windows to each of them and by externalizing user input. Text terminal applications normally poll the keyboard, thus receiving all input that is done to the system. This technique is called internal input, because the input polling occurs inside the application. Internal input makes sharing of input among applications difficult.
All windowing system work with external input. User input is no longer polled by the application, rather the application registers with the windowing system the forms of input that it likes to receive and the windowing system sends a message to the application in case a desired user input occured. Some examples for common messages are clicking on a registered button, or resizing of the application window.
The message passing technique is also well suited to the user-preemptiveness of WIMP interface applications. User-preemptiveness means that the interaction with the application is not restricted to one specific action determined by the application, but rather the user can choose freely from a variety of possible actions which to perform next. To handle these addtional degrees of freedom within the application it is practical not only to share input among several applications but also to share it among objects inside application itself. An example: In a drawing application moving the pointer can cause a line to be drawn or a pull-down-menu to appear, so both entities within the application possibly need this user input. It is straightforward to extend the windowing system that already provides application-wise input sharing to sharing of input among parts of one application that separately register with the windowing system.
A third purpose of the windowing system is to provide a common look-and-feel to the applications. The system provides some set of standard widgets called a toolkit. Each widget has standard behaviour which can be extended by the application. Very common examples for standard widgets are buttons or text input boxes. In the Unix X11 system these toolkits are not part of the system, rather separate toolkit libraries like Motif are available to be linked to the application program.
The last task of a windowing system is more user-oriented. In a comand-line based operating systems the user does its interaction with the system using a shell. For similar administrative purposes a window system has to provide a window manager which allows the user to do administrative tasks within the WIMP interface, for example to open, resize, iconize and close windows. The same window manager is often used to customize the graphical interface, for example the background, the look of application window frames and so forth.
In the X11 system this task is done by a separate application called the window manager. There is a variety of them available for X11, some modern ones are FVWM and AfterStep.
There is a trend to integrate the windowing system along with its toolkit and a window manager into the operating system. Most modern desktop computer operation system such as MS Windows or MacOS follow this path. They provide a uniform look-and-feel to the user, a uniform programming API for graphical interface and operating system functions and can provide integrative features that link windowing system and operating system issues such as interprocess communication. Windows' clipboard or the OLE interface are two examples. A disadvantage of this integration is that the flexibility for separate choices of operating system and windowing system is lost. Changes to either of the systems could influence others, making updating one component while leaving others difficult.
After discussing the various tasks within the windowing server we now look at how the programs make use of the windowing services.
2. Programming Paradigms for Windowing Applications
2.1 Procedural programming languages with message loops
The first approach to programming windowing systems were conventional procedural languages using read-evaluation-loops. Each time the loop is iterated a message is polled from the windowing system, and the appropriate code for the message is executed. All older systems have at least still the capability to be programmed this way.
Message loops are cumbersome in a number of ways. First of all, the centralized input paradigm which we tried to get rid of by sharing input within an application itself is back. All input appears at the message loop first and the programmer has to take care that the various parts of the application receive the appropriate input. We rather want each part of the application to decide on it own which input it needs. In the message loop the code belonging to various user-preempted actions is intermingled rather than separated into modules for each action.
In general procedural languages with their centralized program flow are simply not well suited to the sort of input provided by WIMP interfaces. Next we will look at some alternative approaches that make programming windowing systems more natural.
2.2 Object-oriented languages
Instead of message loops which read messages coming from widgets and branch to some application code which describes the behaviour for each of the messages, in object-oriented languages widgets are wrapped up by classes which are provided either by the windowing server itself or by some overlying library. To create a new dialog item the application instantiates a new object of the dialog control class. Upon creation the widget object registers itself with the windowing system. The application can change the object properties such as visibility, size and position by calling class methods or changing class attributes.
The provided classes can be used as is for widgets without any user interaction such as static text controls.
All other widgets generally require some application-specific behaviour. This is where the real advantages of object-oriented programming come in. Writing message loops in procedural languages separates the code for some widget from the widget itself, the programmer has a very different view on the application when looking at his code than the user has when looking at the dialog of the application. Object-oriented programming avoids this by attaching the code to the dialog control class. In order to change the widget's behaviour the application implements a new class which inherits all its default behaviour from the operating-system-provided widget class. The new class can add application-specific code to the default message handling routines or change the control's default behaviour by redefining some of the methods that handle messages sent to the control.
Examples for the object-oriented paradigm to program WIMP interfaces are C++ in conjunction with Windows and the Microsoft Foundation Classes, Smalltalk, Java or ISE Eiffel with Eiffelbench.
2.3 Prototype-based languages
Class-based object-oriented programming is already a much more natural way to program graphical user interfaces than conventional procedure-based programming with message loops. But there is still some discrepancy in the representation of standard widgets as classes. To change simple widget properties it is often possible to use the widget class unchanged. But to change the control's behaviour a new class has to be written which inherits from the dialog control class and adds new code. This class in turn has then to be instantiated to create a widget with the intended behaviour. This task non-uniformity is due to the additional abstraction layer between classes and objects, classes describing some operations on a data type, and objects providing the data to operate on. While this approach proved to be useful for the data model of a program, it is not very intuitive to write graphical user interfaces.
Prototype-based language do not make the distinction between classes and objects. Rather, everything is an object, and a single feature, inheritance from a prototype object, is used to describe object instantiation and inheritance of code. Changing an object's properties is possible as well as changing its behaviour by inserting some code into it.
In a typical usage scenario of a WIMP interface screen objects form a hierarchical structure. The screen area as the main window has a number of child windows, which are the applications, which in turn contain dialog windows and widgets. The feature of object inheritance in prototype-based languages offers the integration of this hierarchy into the language. Widget objects have now not only their code encapsulated but they are in turn encapsulated by the parent window they are in. The gap between the interface semantics and the programmer's view is narrowed further.
The only widely used language that makes use of the advantages of prototype-based programming for user interfaces is NewtonScript, the programming language for the Apple Newton MessagePad. This innovation was possible because hardware platform, user interface, and programming language were designed at the same time, each of those unusual enough to justify radical design decisions.
2.4 Rapid Application Development languages and scripting languages
Certainly theoretically less sound and more arrising from practical considerations are rapid application development languages. Two examples are VisualBasic from Microsoft and Delphi from Borland. Both languages make use of the familiarity of developers with existing languages. VisualBasic has its roots in the BASIC interpreter history of Microsoft, starting with the very first Microsoft product MS-BASIC. Delphi is derived from Turbo Pascal, also a well-known language which has been around for a while.
Rapid application development languages rely heavily on graphical environments to build the application interface. Rather than coding the interface the programmer picks standard widgets from a toolkit and places them graphically on an application window area. By clicking on these positioned items the programmer can change properties of these objects as well as add code that describes the application behaviour. This looks very much like the unifying concept of the prototype-based approach, although it is much more specialized for interface development. This keeps the programmers from the hassle to learn a new language paradigm, but it also makes the innovative language features avaibable for interface programming only. This is a major difference to the more thorough approaches of class-oriented and prototype-oriented programming languages.
And indeed, the author having some experience with conducting large projects in Visual Basic, this language has major weaknesses when it comes to implementing a larger data model which is not easily described in terms of interface interactions. The code being bound to interface widgets is simply not appropriate anymore.
These languages are also fairly platform-dependent because they rely very much on the existence of certain widget properties and messages. There is no Visual Basic for Unix, for example.
Command line shells normally offer a batch language, a small interpreted language controlled by command line arguments. Similarly, there are scripting languages for windowing systems to build graphical user interfaces. Tcl/Tk is a good example of such a scripting language for the X11 system. Tcl was developed as a programming language to control command-line driven tools of the operating system. The toolkit Tk is an enhancement to Tcl that allows using windows and widgets for script input. The paradigm of programming is rather conventional, widgets are created by a command and script procedures are attached to them to describe their behaviour. But programming this language is fairly easy and quick results can be obtained.
Similar scripting languages also exist for Windows, for example WinBatch, but they are not nearly as powerful as Tcl/Tk.
Surely the final technique to build interfaces not yet been found, but probably some hybrid approaches are most favorable. Delphi is an object-oriented rapid development language. The Visual C++ environment has features similar to rapid application languages, by clicking on an object you see the code associated with it, and also NewtonScript makes limited use of graphical interface design.
3. User Interface Management Systems
For small programs the programmer can concentrate his effort on structuring the user interface parts, with the application functionality and the data model code written somewhere among the interface parts. This no longer works for big projects. In discussing the rationale of prototype-based languages I already said that the abstraction requirements for interface programming and data model representation are rather different, and limitations when concentrating only on interface design are apparent in Visual Basic.
Application architecture for larger systems has to take that into account. Some separation of the interactive, user-preempted interface and the data model has to take place. Several theoretical proposals exist to address this problem. All use some kind of object-oriented application view. The most prominent and oldest of these theoretical models is the Seeheim model from 1985.
Focussing on implementational issues I want to briefly describe the Microsoft Foundation Classes which in conjunction with the Visual C++ development system form a class library which besides wrapper classes for the Windows windowing system provides some UIMS functionality for document-oriented applications. All major Microsoft applications are written using this library. It follows to some extent the model-view-controller separation of Smalltalk. Applications act on one or more documents which provide an interface to their data which includes operations for reading the data in the document, changing it and making it persistent by writing it into a file. There are one or more views bound to each document that read document data in order to display or print it, and write the document data according to user commands given to the view. A lot of standard interface dialogs to the documents are provided by the library, for example for loading and saving a document or printing it which bind either to documents or to views to perform their task.
Some criticism towards MFC is that it is rather heavyweight and also rather restrictive in the way the application looks and behaves. Not all applications are document-oriented and MFC being the only class library Microsoft provides one has to cut it down a whole lot to write other applications. But nevertheless, MFC is a practical tool widely used in the industry.
4. Conclusion
Looking into the future, it is doubtful that the prototype-based language paradigm will be successful. Although it is well suited to the problem of interface programming, to implement efficient compilers is inherently difficult and the advantages over class-based programming are probably not big enough to overcome the substantial inertia of the class-based programming paradigm which has still the edge for implementing data models.
I think that most of the further work in the way we implement WIMP interface applications will go into the refinement of existing development environments and especially into the development of architectural libraries. Building proper GUI application architectures is by far not as well understood as means to program the interface itself, general knowledge in this domain among programmers is still rare and not included in their training, and the existing systems are too complicated and restrictive like MFC or provide not enough support like rapid development languages, so a lot of work is still to do in this domain.
References: