Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/unix/volume2/window/part1/Paper.jacob

Text File | 1986-11-30 | 22.4 KB | 742 lines

.rm CH
.ds CF "\(hy \\n(PN \(hy
.\"
.ds >. .
.rm <.
.ds >, ,
.rm <,
.ds [. " [
.ds .] ]
.\"
.TL
User-Level Window Managers for UNIX
.AU
Robert J.K. Jacob
.AI
Naval Research Laboratory
Washington, D.C. 20375
.AB
.I Wm
manages a collection of windows on a display terminal.
Each window has its own shell or other interactive program,
running in parallel with those in the other windows.
This permits a user to conduct several interactions with the system in
parallel, each in its own window.
The user can move from one window to another, re-position a window, or
create or delete a window at any time
without losing his or her place in any of the windows.
Windows can overlap or completely obscure one another;
obscured windows can be "lifted" up
and placed on top of the other windows.
.PP
This paper describes how such a window manager for UNIX\(dg
.FS
.PP
\(dgUNIX is a trademark of Bell Laboratories.
.FE
is implemented as a set of user processes,
without modifications to the UNIX kernel.
It shows how the simple, but well-chosen
facilities provided by the original
(Version 6) UNIX kernel are sufficient to support
.I wm .
In addition, subsequent versions of
.I wm
exploit features of the kernel introduced into newer versions of
UNIX to provide faster and more sophisticated window operations,
still implemented entirely at the user level.
.AE
.SH
Introduction
.PP
This paper describes the design of a display window manager for
UNIX implemented entirely as a set of user processes, without modifications to
the UNIX kernel.
It shows how the simple facilities provided by the original
(Version 6) UNIX kernel are sufficient to support such a window
manager.
In addition, more recent versions of the window manager exploit
features of the kernel introduced into newer versions of UNIX to
provide faster and more sophisticated operations in windows,
still implemented entirely outside the kernel.
.PP
This window manager,
.I wm ,
provides a UNIX
user the ability to conduct several interactions in parallel, each in
a different window on a text display terminal.
The windows may be created, moved, and temporarily or permanently erased
at any time.
They may also overlap or completely obscure one another, and such hidden or
partially hidden windows may be "lifted" and placed on top of the
other windows as desired.
Figure 1 shows a snapshot of a
.I wm
session in progress.
.SH
User Interface
.PP
The notion of organizing computer data spatially was propounded
and exploited by Nicholas Negroponte in the Spatial Data Management System\*(<.\*([.2,\|3\*(.]\*(>.
In
.I wm ,
however, spatial cues are used only to specify a context for a dialogue.
Once a window is selected, further interactions within that window
make use of the
power and abstraction of more conventional user interface techniques.
Teitelman\*([.8\*(.]
made good use of display screen windows for
a collection of parallel interactions with an INTERLISP system.
More recently, several personal computers and workstations have adopted this
window-oriented style of dialogue as their principal mode of interaction.
Other systems similar to the present one have also been provided
under UNIX\*(<.\*([.4,\|7,\|9\*(.]\*(>.
.PP
Traditional user interfaces for computers
that handle parallel processes
place all inputs and outputs in one chronological
stream, identifying the process associated with each, but interleaving
the data.
The Berkeley job control facilities for UNIX
provide a first attempt at improving this situation\*(<.\*([.5\*(.]\*(>.
.PP
By contrast, a window-based user interface
enables a user to manage a collection of dialogues by
associating a spatial location with each dialogue, in much the same
way one organizes a desk.
On a desk, all input papers on all topics
are not (one hopes) placed on a single
pile in chronological order, but rather they are divided into piles by topic.
When input for a particular topic is received, the corresponding pile
is located, lifted, and placed on top of other papers, and the necessary
work is done on that pile.
Each topic may thus be associated with
and remembered in terms of a location on the desk.
Recent empirical evidence showed that such a window-oriented
user interface induced better user performance than a more
traditional scrolled message interface in a particular
situation involving several parallel interactions\*(<.\*([.6\*(.]\*(>.
.PP
.I Wm
conducts several concurrent dialogues with a UNIX user.
Each takes the form of a UNIX shell, to which
UNIX commands can be given and from which other interactive
programs can be initiated.
Each dialogue is conducted in a separate area of the screen or
.I window
designated by the user.
At any moment, one of the windows is considered the current input window,
and all keyboard inputs (except for
.I wm
commands themselves) are sent to the shell
or program associated with that window.
At any time (including in the middle of typing a command in a window),
the designation of the current window may be changed
and a different dialogue begun or resumed.
Outputs resulting from these dialogues will appear in their appropriate
windows as they are generated, regardless of which window is the
current input window.
Output destined for a portion of a window that is obscured by another
window will appear whenever that portion of the window is uncovered.
Windows can be "piled" on one another in any sequence.
.PP
.I Wm
was originally designed for use in an intelligent terminal
that could communicate with several computers simultaneously.
Each dialogue with a different computer was associated with a window.
The method is equally applicable to a collection of dialogues,
all with the same computer but on different topics.
Still, any or all of the present windows can run programs to conduct
interactive dialogues with other computers
(such as
.I telnet ).
.SH
Design for "Vanilla" UNIX
.PP
To implement a system of this sort,
it is necessary for one user process to be able to
manage a collection of other user processes and to mediate all of
their inputs and outputs.
For the inputs, it must act as a switch, directing input from the keyboard to
different programs in response to user commands.
For the program outputs,
it must place the output of each program in its correct
position on the screen.
.PP
If adequate primitives for creating and manipulating processes
and for catching their inputs and outputs are provided by the
operating system, a window manager can be built entirely as a
user program.
The original design of UNIX, with its
.I pipe
and
.I fork
mechanisms provides a user the right primitives to design such a
system in an elegant fashion without kernel modifications.
.PP
.I Wm
initiates and manages its own collection of UNIX processes, including
those run in response to entered commands.
Any conventional UNIX program can be used from
.I wm ,
provided it does not make significant
assumptions about the nature of its input
and output devices\-that is, it should treat input and output from a
pipe as equivalent to input and output from a terminal or other source.
.PP
.I Wm
runs as
.I 2n+2
parallel UNIX processes of four different types
(where
.I n
is the number of windows in use).
The division into processes is dictated by the fact that the original UNIX
.I read
call on an empty pipe or input device causes a process to
block until input becomes available.
Hence there is a separate process for each pipe or device that must be
read asynchronously.
Each such process contains a loop that reads from its
particular pipe or device,
processes the input, and then waits for more.
Figure 2 shows the processes and pipes that comprise
.I wm .
.PP
The
.B main
process reads from and waits for input from the keyboard.
Input consisting of text is sent to the shell process
associated with the current window and also to the
.B scrn
process, described below, for echoing.
Input consisting of
.I wm
commands is interpreted by
.B main ,
translated into one or more primitive commands plus arguments, and sent to
.B scrn
for execution.
Simple changes in the input command language are thus localized in
.B main .
To change the name, input syntax, or prompt for a command, only the code in
.B main
need be modified.
Since input commands are reduced to a somewhat more general set of
primitive commands, some simple new commands may be implemented entirely in
.B main
as aliases for specific uses or combinations
of the existing primitive commands.
.PP
The
.B scrn
process handles all outputs to the screen.
All processes that want to affect the screen must thus place requests
to do so on a common pipe.
.B Scrn
reads these instructions from the pipe and makes appropriate modifications to
the screen.
.I Wm
commands that affect the screen layout, such as moving a window, are placed
on this pipe by
.B main
and handled by
.B scrn .
Output text characters from the individual shell processes
that belong in a window
are also placed on this pipe along
with a window identifier and a bit
indicating whether the character should be displayed immediately or
just remembered for the next time the display is refreshed.
.B Scrn
then compares the desired configuration of the screen to a buffer
containing the actual configuration
and transmits the necessary updates.\(dg\
.FS
.PP
\(dgThe update algorithm
is less sophisticated than the optimization performed in the
.I curses
package\*(<,\*([.1\*(.]\*(>,
but
.I curses
was not available in Version 6 UNIX.
This update algorithm
is also somewhat easier to adapt to unusual terminals, as seen below.
.FE
.PP
There is a
.B shell
process associated with each window.
This is simply the standard UNIX
.I sh
(or any other designated program).
These
.B shell
processes have no direct access to the terminal, but run as captives of
.I wm ,
connected by pipes, so that their inputs and outputs can be mediated.
The input to each of these processes is a pipe from
.B main ,
since
.B main
knows which window is the current input window and can place the typed
input text on the pipe to the corresponding
.B shell
process.
All outputs of the
.B shell
processes must be sent to
.B scrn
to be displayed, but they must first be tagged with the name of the
window in which they belong.
.PP
To do this, each window has a
.B shmon
process that monitors the output of the corresponding
.B shell
process.
The output of each
.B shell
process is a pipe to a corresponding
.B shmon
process.
Each time output appears on that pipe,
.B shmon
reads it, packages it with a header identifying its window,
and then places it on the common request pipe to
.B scrn .
.PP
.I Wm
comprises about 1000 lines of C code\-about 500 each for the
.B main
and
.B scrn
processes and less than 50 for the
.B shmon
process.
.SH
Remarks and Problems with "Vanilla" UNIX
.PP
Each window in
.I wm
emulates an individual glass teletype.
Inputs appear in the bottom and scroll off the top of a window.
Since the standard input and output for all programs run by
.I wm
are really pipes,
all programs run under
.I wm
should treat their inputs and outputs
simply as streams of characters, without distinctions between
terminals and pipes.
The fact that UNIX and most of its original programs permit a pipe to be
substituted for a terminal input or output stream is an elegant
aspect of UNIX that is crucial to
.I wm .
This obtains for most UNIX programs;
they perform individual "building-block" functions and are thus intended
to be equally usable individually from the terminal
or as filters connected to other programs to perform more complex tasks.
Programs that try to determine whether they
have access to a real terminal may behave differently or even refuse to run with
.I wm .
For example,
.I stty
is meaningless when applied to a pipe rather than a terminal,
.I vi
will refuse to run from a pipe,
and
.I csh
will not allow job control if it cannot access the terminal.
(However, note that
.I wm
is really an alternate approach to controlling concurrent jobs.)\
.PP
A very rudimentary facility for supporting a
whole-screen-oriented program is provided.
It creates a special temporary window,
creates a
.I termcap
description of a "terminal" that occupies only the corresponding
area of the actual
screen, and then provides that description and direct access to the terminal
to the screen-oriented program until the latter exits.
.PP
Since
.I wm
operates with the terminal in raw mode,
it must provide for itself the input line editing functions normally
provided by the teletype driver.
.PP
Because of the architecture of
.I wm ,
there are no pipes that
connect one window to another, hence there is no explicit facility for
communication between windows.
It can be achieved, however, through the file system.
A program in one window
can append to a file while one in another window continuously tries to read
from the end of that file.
.SH
Terminal Dependencies
.PP
While the newer version of
.I wm
uses
.I curses
to perform all terminal-dependent operations in a
terminal-independent fashion, terminal dependencies can be
isolated fairly easily even without
.I curses .
All terminal-dependent code in the original
.I wm
is restricted to a collection of five simple procedures.
They were originally written separately for each type of terminal,
but have also been written in terms of the terminal-independent interface,
.I termcap ,
for systems that have it.
.PP
The five procedures perform the following tasks:
.RS
.IP \fBttyinit\fP 15
Performs any necessary initialization for the terminal.
.IP \fBttyclose\fP 15
Performs any necessary closing for the terminal before
.I wm
exits or suspends.
.IP \fBttymov\fP 15
Moves the terminal cursor to a given row and column.
.IP \fBclearscreen\fP 15
Clears the terminal screen.
.IP \fBclearline\fP 15
Clears from the cursor to end of the current line
(not mandatory).
.RE
.LP
For each of several common terminals, the definitions of these
procedures comprise about 15 lines of code altogether.
.PP
This approach isolates terminal dependencies sufficiently that
.I wm
can also be adapted for use on graphic displays
by replacing the above procedures and making other minor changes.
Such a version of
.I wm
has been written to produce output suitable
for the standard UNIX plot filters (plus some added commands for
raster graphic displays) and used with a Genisco frame buffer.
Windows may be in various colors and may use different fonts for their text.
.SH
Design for Version 4.2 UNIX
.PP
Berkeley Version 4.2 VAX UNIX provides new features that make it
possible to improve
.I wm
significantly.
By using pseudo-terminals instead of pipes for interprocess
communication, several of the problems discussed above disappear.
In addition, the synchronous input/output multiplexing feature of
the new UNIX makes the former division of
.I wm
into processes as dictated by the blocking read unnecessary.
A revised version of
.I wm ,
then, solves many of the earlier problems and runs in a single
process (plus the user's shells).
It is, however, less interesting and certainly less portable than
the initial version.
Again, the facilities are provided entirely in user-level processes,
without the need for kernel modifications.
.PP
This version of
.I wm
reads from the keyboard and also from the pseudo-terminals associated
with each window, in a round-robin, using the multiplexed read call
.I (select) .
Keyboard input consisting of text is sent to the pseudo-terminal
associated with the current window.
The pseudo-terminal driver itself handles
echoing (when enabled) and intraline editing,
obviating the need for
.I wm
to duplicate these functions.
Keyboard input consisting of
.I wm
commands is processed directly;
text input is sent to the appropriate pseudo-terminal.
Output from the pseudo-terminals is read by
.I wm ,
interpreted in terms of
the cursor control commands of a simple virtual terminal defined by
.I wm ,
and then added to the appropriate screen window for processing by the
.I curses
package\*(<.\*([.1\*(.]\*(>.
.PP
This version of
.I wm
comprises about 1000 lines of C code, all in a single process.
Figure 3 shows the architecture of the program.
.SH
Remarks and Problems with Version 4.2 UNIX
.PP
Since each window is implemented with a pseudo-terminal, the fact
that a program is running in a window rather than on a real
terminal is transparent to most programs.
Specifically,
most screen editors and games may be used, and
.I stty
may be called to change characteristics such as echoing or line editing
individually for each window.
For example, note that one of the windows in Figure 1 is running
.I vi ,
which has adjusted itself to the window size.
Some programs, however, assume that their output devices are
of some minimum size;
they will not run well in very small windows.
Also, programs that attempt to manipulate the controlling
terminals of process groups will not work properly under
.I wm .
For this reason,
.I csh
cannot currently be run in the individual windows instead of
.I sh .
.PP
It is generally
not possible to move a window while an interactive
program (other than a shell) is running in it.
First, this is necessary because, whenever a window is moved,
.I wm
sends a shell command to change the
.I TERMCAP
variable for the shell in that window, to describe its new size.
A more fundamental reason is that the
.I curses
library routines (sensibly)
do not expect the terminal description to change while
a program is running, and so make no provision for checking for or
adapting to such changes.
.PP
Since pseudo-terminals are a system-wide resource and are usually fixed in
number, the total number of
windows that can be in use by all users at any one time
is limited to the number of pseudo-terminals made available to
.I wm .
.PP
A facility for communicating between windows is now easy to provide.
Since each window uses a pseudo-terminal, any data sent to its
slave pseudo-terminal
will appear in the window;
and pseudo-terminals are in the name space of the UNIX file
system and thus available to other processes.
To simplify use of this feature, when a window is created and a
pseudo-terminal obtained for it,
a link to the name of its slave pseudo-terminal is created
in the user's current directory.
Any program inside or outside
.I wm
can then write to or read from that file name without prearrangement.
.SH
Program Versions
.PP
These programs are written in C for use with UNIX.
There are three principal versions:
.B wm.v6 ,
.B wm.v7 ,
and
.B wm.v42 .
The first, as described above,
runs under unmodified Version 6 UNIX on a PDP-11.
The code for this version was frozen and abandoned several years
ago, but it is still available.
.B Wm.v7
runs under Version 7 UNIX,
and the same code also runs on Berkeley 2.8
and also on a VAX on Berkeley 4.1 and 4.2.
No changes in the source code are required between the PDP-11
and VAX, except that constants for the maximum number and size of windows
are limited by the available memory on a PDP-11.
This version
is similar in design to
.B wm.v6 ,
which was described above, but has a number of improvements.
The newest version,
.B wm.v42 ,
runs only under Berkeley 4.2 on a VAX,
as described in this paper.
It uses the
.I select
synchronous input/output multiplexing call,
which is unique to 4.2, and also other features
that are found in some, but not all, versions of UNIX, such as
pseudo-terminals and
.I curses .
At this writing, this version is not yet thoroughly tested on 4.2.
An intermediate version for use with Versions 2.8 or 4.1
can also be constructed by adapting some of the features of
.B wm.v42
to
.B wm.v7 .
For example, the use of
.I curses
can certainly be adapted to 2.8;
pseudo-terminals are available on some versions of 4.1;
and some versions of 4.1 can also simulate a non-blocking read
on a pseudo-terminal or a short time-out.
.SH
Availability
.PP
Three versions of
.I wm
are available to interested researchers.
.RS
.IP "\fBwm.v6\fP" 10
For Version 6 UNIX.
.IP "\fBwm.v7\fP" 10
For Version 7 UNIX, also runs on Berkeley 2.8, 4.1, and 4.2.
.IP "\fBwm.v42\fP" 10
For Berkeley 4.2 UNIX only (but has some features than can be retrofitted to
.B wm.v7 ).
.RE
.LP
The code can be obtained over the Arpanet by sending a request to
.\" the two (hy is to prevent the hyphenation algorithm from splitting nrl-css
jacob@nrl\(hycss.
The author can also be reached via uucp
at ...!decvax!linus!nrl\(hycss!jacob.
.SH
Conclusions
.PP
It is demonstrably feasible to provide a useful and efficient
display window management facility in UNIX at the user level,
without support from kernel modifications.
Such a facility can even be provided for the original Version 6 UNIX,
although some improvements are obtainable by exploiting features
provided by more recent versions of UNIX.
.SH
Acknowledgments
.PP
I would like to thank
Mark Cornwell, Rudy Krutar, Alan Parker, and Mark Weiser
for helpful discussions of this work.
.]<
.\"Arnold.K.-1980-1
.ds [F 1
.]-
.ds [A K. Arnold
.ds [T Screen Updating and Cursor Movement Optimization
.ds [R University of California, Berkeley
.ds [D 1980
.nr [T 0
.nr [A 0
.nr [O 0
.][ 4 tech-report
.\"Bolt.R.-1979-2
.ds [F 2
.]-
.ds [A R. Bolt
.ds [T Spatial Data Management
.ds [I Architecture Machine Group, Massachusetts Institute of Technology
.ds [R Technical Report
.ds [D 1979
.nr [T 0
.nr [A 0
.nr [O 0
.][ 4 tech-report
.\"Herot.C.F.-1980-3
.ds [F 3
.]-
.ds [A C.F. Herot
.as [A ", R. Carling
.as [A ", M. Friedell
.as [A ", and D. Kramlich
.ds [T A Prototype Spatial Data Management System
.ds [J Computer Graphics
.ds [V 14
.ds [N 3
.ds [P 63-70
.nr [P 1
.ds [D 1980
.nr [T 0
.nr [A 0
.nr [O 0
.][ 1 journal-article
.\"Horton.M.-1982-4
.ds [F 4
.]-
.ds [A M. Horton
.ds [I personal communication
.ds [D September 8, 1982
.nr [T 0
.nr [A 0
.nr [O 0
.][ 2 book
.\"Joy.W.-1980-5
.ds [F 5
.]-
.ds [A W. Joy
.ds [T An Introduction to the C Shell
.ds [R University of California, Berkeley
.ds [D November 1980
.nr [T 0
.nr [A 0
.nr [O 0
.][ 4 tech-report
.\"Murrel.S.-1983-6
.ds [F 6
.]-
.ds [A S. Murrel
.ds [T Computer Communication System Design Affects Group Decision Making
.ds [J Proc. Human Factors in Computer Systems Conference
.ds [D 1983
.ds [P 63-67
.nr [P 1
.nr [T 0
.nr [A 0
.nr [O 0
.][ 1 journal-article
.\"Pike.R.-1983-7
.ds [F 7
.]-
.ds [A R. Pike
.ds [T Graphics in Overlapping Bitmap Layers
.ds [J ACM Transactions on Graphics
.ds [V 2
.ds [N 2
.ds [D 1983
.nr [T 0
.nr [A 0
.nr [O 0
.][ 1 journal-article
.\"Teitelman.W.-1979-8
.ds [F 8
.]-
.ds [A W. Teitelman
.ds [T A Display Oriented Programmer's Assistant
.ds [J International Journal of Man-Machine Studies
.ds [V 11
.ds [P 157-187
.nr [P 1
.ds [D 1979
.nr [T 0
.nr [A 0
.nr [O 0
.][ 1 journal-article
.\"Weiser.M.-1983-9
.ds [F 9
.]-
.ds [A M. Weiser
.as [A ", C. Torek
.as [A ", R. Trigg
.as [A ", and R. Wood
.ds [T The Maryland Window System
.ds [R Technical Report 1271
.ds [I Computer Science Department, University of Maryland
.ds [D 1983
.nr [T 0
.nr [A 0
.nr [O 0
.][ 4 tech-report
.]>