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.
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:
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.
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:
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.
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.
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:
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.
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 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:
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.
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:
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:
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.
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.
