4. Ten Years of Window Systems - A Retrospective View

Warren Teitelman

4.1 INTRODUCTION

Both James Gosling and I currently work for SUN and the reason for my wanting to talk
before he does is that I am talking about the past and James is talking about the future.
I have been connected with eight window systems as a user, or as an implementer, or by being
in the same building! I have been asked to give a historical view and my talk looks at
window systems over ten years and features: the Smalltalk, DLisp (Interlisp), Interlisp-D,
Tajo (Mesa Development Environment), Docs (Cedar), Viewers (Cedar), SunWindows and SunDew systems.

The talk focuses on key ideas, where they came from, how they are connected and how they evolved.
Firstly, I make the disclaimer that these are my personal recollections and there are bound to be some
mistakes although I did spend some time talking to people on the telephone about when things did happen.

The first system of interest is Smalltalk from Xerox PARC.

4.2 SMALLTALK

I was at the meeting where Dan Ingalls came up with the good idea of windows in Smalltalk.
The ideas in the Smalltalk window system have propagated rapidly and most of the groups at Xerox PARC have used
others' good ideas in their own environments.

Smalltalk had the first real window system. It used overlapping windows. In the early system you could only
interact with the window that was on top, like a desktop. This simplifies the window system, but many people felt
it was disadvantageous and this was subsequently corrected in later versions.

Smalltalk was the first system to use a cut and paste, modeless editor. Modeless editing was originally
introduced in the Gypsy text editor at PARC, but Gypsy was not a full window system.
Bravo [35] had the first display editor that had exposure at PARC.
It was a fancy modal text and format editor. It had text insertion mode and command mode and it was easy to
forget that you were in insertion mode and to insert commands into text, and conversely to delete a document
accidentally when in command mode. Cut and paste eliminated modes. Anything typed is text directed at an
insertion point which can be moved with the mouse. Insertion is a form of pasting, and cutting is a form of
moving so two simple commands form the basic model which is very attractive. The Laurel message system included
a text editor that allowed two ways of operating: modal and modeless, but gradually users all moved to modeless
operation.

Smalltalk-76 [26]
[27] was developed on the Alto, a 16-bit machine with 64 Kbytes
of memory. A lot of concern went into fitting the system onto this small machine with its small virtual address
space and it proved to be good for prototyping only.

Smalltalk-80 [21] was designed with the Dorado in mind.
This was a real system with large virtual memory, dynamic storage and garbage collection and Ethernet communications.

Slides from Small talk systems showed:

an early A4 picture of a nut and bolt (Figure 4.1);

a clock (from a 1983 system): a system is shown to be maturing when clocks and games appear;

Figure 4.1

The Smalltalk language has methods and submethods for inheritance and subclassing which
is something we intended to do in Interlisp and Cedar but never got round to doing.

4.3 DLISP

I wrote DLisp [60] which was first presented in 1977 at MIT.
This system was a hybrid implementation involving the Alto and MAXC (PDP-10).

The Lisp part of the system communicated with a server running on the Alto which handled communications
with the screen. The server could do things such as put up rectangular areas on the screen, but had no knowledge
of windows as all the window information was in the Lisp. Communication between the Alto and Lisp was by packets
over Ethernet. The idea of using this architecture belongs to Bob
Sproull. The system worked amazingly well although the user interface had to be tailored to the
limitations of the machine. For example, you could not drag images, nor could cursors be changed in
response to moving in and out of areas.

Most of the user interface was concerned with timeout. A special character in the input stream signalled a
mouse event and there was a special event when there was no activity.

The system was completed in 1977 but was not heavily used. it provided the starting point for Interlisp-D.

The editing paradigm was not cut-and-paste and the interface was awkward and
menu-driven. The editor allowed textual editing with some knowledge of list structure.
The system had built-in document classes such as text, desktop, window and canvas which were predefined.
These classes could not be extended.

The key ideas of the system are described below.

Partially obscured windows were treated in the same way as the window on top, for example characters could be
typed into them.

This system provides the first support for multiple fonts. (Smalltalk used a single font.)

Windows in DLisp were defined descriptively rather than procedurally ( a Lispish
idea). Programs could also pass a set of specifications to be put in front of
existing specifications. This made it easy for users to tailor their own systems as it
involved editing data structures, not programs. A program could also search a
specification list to see if a particular specification was present. This idea did not
catch on widely, however.

The system provided support for multiple views, ie recursive windows. An example
of this is the Morton Salt Box label in which the product label has a picture of
itself which has a picture of itself etc.

There was no explicit notion of display context. If you positioned the mouse in
a window and scrolled it then all occurrences of the window on the screen with
their appropriate offsets had to be found and scrolled. The idea of transformation
and scaling being represented in data structures had not been thought of yet.

There were various schemes for handling the complexity of the display such as: a
window going grey and fading away if not touched for a period of time; and the arrangement of related windows into desktops. The latter
scheme then required a
tool to navigate around desktops. The later idea of icons is a much better solution.

Slides of this system showed:

a standard typescript interacting with the system, with different fonts, a clock etc;

a menu of menus, rather than a stack of menus;

an error occurrence, when an appropriate menu comes up showing, for example, the call stack;

a mail system for the first time integrated in a graphics environment

Both Smalltalk and this system are single address space systems so the problem of
referring to a data structure in another address space does not arise.

In DLisp there was the notion of commands referring to the current window, and the currently
active window had a distinguishing pattern in its name stripe.

4.4 INTERLISP-D

The Interlisp-D [12] system that was implemented on the
Dorado initially included DLisp but the DLisp code eventually disappeared. Interlisp-D also runs on the Dandelion.

Interlisp-D was a real system with about 1000 users and was influenced by Smalltalk: it was an object-oriented
system. There were 20 classes of objects that could be displayed and users could add their own objects.

Initially there were no multiple processes or monitors although you could switch between tasks
via the caller - callee relationship. Later, as a result of the influence of Cedar/Tajo, multiple processes
and monitors were added. This involved finding and fixing all the places in the code where the system
accessed global resources. There is no preemptive scheduling in the system (yet).

Retained (or cached) windows were added, initially for speeding up performance, for example
with menus, but later retained windows were found useful for hiding from the programmer the fact that
his window was not on top.

The text editor in this system was modeless. It also allowed a mixture of a markup (bitmap editor)
style interface with text.

4.5 TAJO (MESA DEVELOPMENT ENVIRONMENT)

At the same time as PARC was working on Cedar, work was going on in Systems Development Division of Xerox on
developing a graphically-oriented Mesa development system called Tajo [41]
[55]
[68]. Tajo was begun in 1977 and was used by Cedar
implementers between 1980 and 1982.

In Cedar they took Mesa and added storage management, atoms and lists to it. The Systems Development Division
were unwilling to incorporate these changes.

Tajo was a multiple process, integrated, interactive program development environment with scroll bars,
subwindows, pop-up menus etc. It used a 3 button scheme for scrolling with the mouse.

The key ideas of Tajo are described below.

Tajo was the first system to use the notion of two states of a window: open and closed (iconic).
Initially a closed window was represented by a small labelled rectangle on the right of the screen.
As it was difficult to determine the contents, pictorial representations were used very shortly afterwards.

The other interesting thing about Tajo was the control structure used. In the traditional approach the program
believes it is in control of its environment and it controls interactions with the user. The order in which user input
is requested (sequentially), is driven by the convenience of the implementer of the tool, not that
of the user. In the Tajo approach, the program passes in a procedure and specifies to the window manager
an event or events of interest and the procedure is called under window manager control when a specified
event occurs. The user is in control: Tajo interacts with the user until the user indicates do it, when Tajo
notifies the appropriate tool that some user action intended for it has taken place. The tool obtains its
parameters by means of system-managed forms. The user could walk his way through a tool and then leave things
to the window manager, with the program just extracting the data. The problem is that programs have to be
written in this way - they say you have to "turn your programs inside out" as compared to conventional
structure. SUN is addressing the issue of this programming style.

Slides on Tajo showed:

an example of a control panel showing rudimentary icons;

buttons used to activate processes; the application program does not worry about placements, it is just called;

mail system.

Tajo was fairly widely used and was a development environment for the Star. It is still in use.

Tajo was the first system to use static menus. It was found that pop-up menus were good for new users,
but that the same interface that is easy to learn is not necessarily good for experienced users. The user
has to wait for a menu to come up and then has to scan it visually for the relevant entry. A static menu
is already there and the user can mouse-button ahead in a reflexive way.

A Tajo user could also edit what he wanted into a static menu and the system would search the
pop-up menu for that string and call the associated procedure.

Tajo influenced both Viewers and SunWindows.

4.6 THE DOCS SYSTEM (CEDAR)

Docs was developed in 1980 and 1981 but had serious performance problems and was not completed.
It was influenced by DLisp and was the first system to use the Cedar Graphics Model which was a prerunner
of the Adobe Imaging Model [69]
(a data structure with all the scaling, transformation etc information).

The system had the same idea as DLisp of using data description for windows and documents,
but there seemed to be a preference for procedural window interfaces at the time.

The key ideas of the system were as follows:

the system provided support for scaling and rotation (via Cedar Graphics);

there were retained windows;

Docs was object-oriented and had support for subclassing;

the separation of a window from the object being displayed in the window (this was not the case in Viewers):

the ideas of documents, document classes (string, file, window, drawer, stream) and viewboxes
which have home and target documents;

that a document has a procedure for presenting itself in a viewbox;

the notion of view boxes existing in a document, and of viewing a document, which has the potential for recursion.

4.7 VIEWERS (CEDAR)

The current window system in Cedar is based on the Viewers Window Package [40]
[65]. Its design and implementation began in 1981 and the
system had its first users in May 1982. Its influence can be seen in Microsoft's MS-Windows. It was decided to
sacrifice some flexibility for performance and robustness. Consequently Viewers had less functionality but better
performance than Docs, came up quickly, and worked well.

Viewers is a notification-oriented system, as a result of the influence of Tajo, and is also object-oriented
with a number of objects in the system.

Whiteboards in the system are a spatial way of presenting objects and were influenced by
Smalltalk browsers. Neither Cedar nor Viewers support subclassing. As a result, it is necessary to duplicate and
edit code to provide an object which may be only slightly different from an existing object.
Subclassing was supposed to be provided but just did not get implemented.

The key ideas in Viewers are detailed below.

This was the first tiling window manager that I know of. This makes for faster mouse hit detection.
I was originally from an environment of overlapping windows but found that I preferred using a tiling window manager.
There are conflicting views on this however. You can mouse ahead but some discipline must be involved
in doing this. Predictability is important from the user point of view but Cedar went too far in not
allowing overlapping windows and thus also not allowing pop-up menus. I think it is a good idea to
allow transitory windows in overlapping mode. The SUN allows overlapping windows but it is surprising
how many people take the trouble to tile.

Another novel idea is the TIP (Terminal Interface Package), which provides for the separation
of the function of the system from the particular user interface used to invoke that function.
By changing a data structure, a new interface can be obtained. The user can tailor the interface.
Although sensible defaults are provided, the fact that the user can change things makes agreement
on the interface less of an issue. Not everyone will want to spend the time tailoring a system and
a complaint about Unix software is that it has not aged sufficiently for sensible defaults to be provided.

The flexibility of the system is shown by an example of how events associated with mouse buttons
can be changed in the TIP to obtain a new user interface. This idea has been retro-fitted to Tajo
and is planned for James Gosling's new system, SunDew.

Slides on this system show:

richer icons (Figure 4.2) - this raises again the question of what you should be able to
do with icons, eg type at them, delete them etc;

the built-in notion of the screen being divided into two columns (Figure 4.3);

typical screen configurations showing the use of multiple fonts and (Figure 4.4, Figure 4.5)
the notion of text being organized as a tree structure which enables the user to specify the depth to
which he wants to go and also allows nodes to be moved around;

an example of a more sophisticated tool: an Icon editor, with a user
interface defined by a TIP table (Figure 4.6);

a scanned image clipped to the outlines of characters defined by splines which reveals the
strength of the graphical underpinning of the system (Figure 4.7).

The shortfalls of the system are that there is no support for subclassing; that viewers can only be specified
via programs and not data; and that there is no separate notion of a viewer and an object being viewed.

Figure 4.2

Figure 4.3

Figure 4.4

Figure 4.5

Figure 4.6

Figure 4.7

4.8 SUNWINDOWS

SunWindows [61]
[62]
is an attempt to bring windows to a Unix system. It has synchronization problems
of a multi process environment that I find objectionable. The problems are aggravated
by multiple address spaces, which means that the protocols with which you are
communicating have to be worried about.

There are three ways to partition the function of window management:

in the same address space as the client process - this requires replication
of the window system library in each application and makes large demands on disc space;

outside the address space of the client in the kernel of the operating system;

outside the address space of the client in a server process - this requires
remote procedure call support, which has not been available in Unix systems until
recently.

SunWindows uses the first two. The disadvantages of this are: inadequate debugging
tools, coupled with the fact that you need to program the window manager in a
different style if it resides in the kernel; bugs in the window system threaten
the integrity of the entire system; no parallel development of applications and
user interface is possible; and there is a large body of code in wired-down memory.

Examples from Sun Windows are:

a graphical interface to the Unix formatting utility indent, which is a
format program allowing different styles;

different options for scrollbars, buttons and bars - the move is towards libraries
that users can build on in the Unix spirit;

an icon editor which has graphical images, a preview area etc;

a tool for manipulating full-screen crosshairs.

I believe that the system must provide hooks for users to do what they want.
The window system cannot legislate on taste.

Finally, the last system to be considered is SunDew.

4.9 SUNDEW

SunDew (see Chapter 5) is an extensible
distributed window system. The window manager is in a user process. In it applications
communicate with the window system via programs written in PostScript. James Gosling
will discuss this system.

4.10 DISCUSSION

Chairman - George Coulouris

Myers:

It might be worth mentioning that the current system on BLIT uses many
of the same ideas as DLisp.

Teitelman:

Yes, that is another case where you have a separation of the window management
function from the application program. The good ideas in that area came from Bob Sproull.

Williams:

You mentioned TIP, does that deal with dragging and pointing actions?

Teitelman:

One of the pseudo-events that it recognized was mouse-move so you could put
into your TIP table that every time the mouse moves I want the following event to be
generated in which case you would continually get mouse-move events. If you did not
have that event in the TIP table, you would not see those events. You could even
specify how often you wanted it depending on whether you were interested in just the
final end point or the whole trajectory.