Pre Smalltalk

No standard terminal architecture for display or screen type terminals has emerged. If one includes with the features of terminals that are now common, the features of terminals that seem certain to be common in the next few years {Teletex, e.g.} then there seems to be no move toward such a common set of ideas, let alone a de facto standard.

I conclude that there will be no TTY of the world of display terminals. As the old terminal support grew about such a de facto standard, what are we to do to gain some of the flexibility that we enjoyed when we could hook up any kind of terminal with any kind of application?

I list here some of the ideas that seem likely to become important for us to support. Some of these ideas are incompatible except at extreme cost.

Features discernable at the terminal.
Variability of font including:
underlining, italics, other type-fonts, color, size, orientation, blinking, intensity, reverse-video, slant and aspect ratio.

Features known to the Program
Moving rectangles from one position to another and subsets of this ability. {This includes scrolling.}

Scrolling continuously.

Invisible storage in the terminal where data that is likely to be redisplayed can be cached.

A variety of information compression techniques.

Host-loadable fonts.

And a large variety of graphics abilities that I am unable to categorize.

The above parameters are still insufficient to describe terminals such as the IBM 3270 wherein the screen serves as a two-way communication device.

I propose a scenario that might be described as a lack of strategy.
Various terminals will be designed by architects mainly outside of Tymshare and be attached via Tymnet. We will provide raw circuit access to these terminals. Programs will be designed for Gnosis domains that provide whatever standard function is commonly required for that terminal at the host end.

When this has happened for several such terminals the anarchy will be painful and we will write adaptors. An adaptor will mate a program written for one terminal to another terminal.

This lack of strategy would seem to result in a large number of adaptors but note that not all members of the cross bar need be filled in. The adaptors are written only after we know much more about these wonderful terminals than we now know. Indeed the adaptor will sometimes be customized to the application.

Adaptors may be stacked. This practice has approximately the same viability as stacking electrical adaptors, to wit, they are flaky and loose power. Stacked adaptors do, however, fill the need for occasional mating of programs to terminals.

Perspectives on the Above
The above strategy could evolve to a de facto standard if some terminal came to dominate the market. If that terminal had features sufficient for many applications then many applications would migrate to it. Other adaptors would soon be required for programs that did not know that terminal. Gradually thereafter we have a defacto standard. Eventually we also have most of the benefits of a standard.

There are a variety of things in the world besides terminals and applications that have a stake in standards:

Editors, callable from an application, need to know as much about a terminal as most application programs.

Window managers are a tool that should ideally be separated from both the terminal logic and application logic.

Command languages may have special needs in this area.

Other Fancy terminal support ideas
BRUWIN style windows
An especially interesting set of {implemented} ideas appear in
BRUWIN: An Adaptable Design Strategy for Window Manager/Virtual Terminal Systems; Norman Meyrowitz, Margaret Moser; Proceedings of the Eighth Symposium on Operating Systems Principles; Vol 15 No. 5 December 1981; ACM Order No. 534810

These ideas seem particularly appropriate for Gnosis. Within Gnosis it becomes natural to speak of transferring windows among terminals for there is no issue of what user a window or terminal belongs to to obscure the meaning of such a transfer. Windows can be transferred thru the mail as a capability.

Augment style Windows
Augment's windows are more and less than those of BRUWIN.

In the BRUWIN scheme each window looks on a separate object. In Augment two windows can show two aspects of the same object. A change to an object via either window may be seen thru both windows.

In augment there is an idea that the window shows you the current state of an object. This is an elusive thing to generalize. It is accomplished in Augment by integrating the window logic with the higher level logic.

Disconnected jobs
Windows should have a life beyond a terminal session. You should be able to tuck a window safely in a directory, or send it thru the mail.

Windows as a Capability
In the BRUWIN system, windows serve as capabilities. They both name and provide the {sole} means to influence something.

Terminals with two screens
Personal subjective experience with the CDC 6600 operator's console leads me to believe that two independently controllable screens is a great advantage in many situations. I do not know if the effect is due to the increased area available or the subjective independence of the two screens.

I presume that a window manager for a single screen with equivalent area and resolution would be even better.

Shared windows (Dual Controls)
If we could duplicate and move a window to the screen of another terminal in another city we would have another type of teleconferencing and application support.

Such windows might be weakened so to prevent the user of the terminal from effecting the object behind the window.

Display Debuggers (Domains and other)
A domain debugger could modify the domain transparently to the logic of the domain so as to cheaply wait for events in the domain. DDT doesn't now do this.

Stanford AI has provided display debuggers for several years that continuously showed values of selected variables associated with the program.

There is no inexpensive way to monitor for changes to a segment given only a segment key, but PER can provide this function efficiently in some cases for modifications made by the domain.

Mapping TTY's onto Displays
The most obvious deficiency of a display compared to a paper terminal is the loss of data after about 20 lines has been printed. An adaptor is needed that keeps this data available for browsing. Deleting real and virtual paper present roughly the same problems.

Impact of these ideas on application programs.
Application programs should contemplate being flexible by interrogating the terminal to learn its strengths and weaknesses. Perhaps we might have a terminal coercer that is in charge of negotiation and provision of adaptors to connect a terminal with an application. The coercer might be in a position to find the least common denominator between the real terminal and the application.

Standard structure browsing and editing functions
We should have some standard ways to edit structures. The most common such structure is the character string.

This is a function that pervades applications and terminal design.

It is a very frequent reason that an application gets locked into a particular type of terminal. An excellent example of this is the PLIC compiler. This compiler from IBM has a highly integrated editor. The editing style is obsolete. It fails to take advantage of either newer and more familiar ideas or hardware.

A great deal of application logic may be viewed as merely conversing with a person at a terminal about some abstract object and allowing that person to cause changes in that object. I think that a system that provides general and uniform structure editing will gain great loyalty and indeed fanaticism on the part of the user.

I suspect that a great deal of the fervor with which users of System 38 praise that system is the uniformity with which users talk to the system about complex objects.

One view is that a data base system {perhaps relational} talks about objects of sufficient complexity to model these structures. I don't think, however, that I want to think of my PL/I program as a Magnum data base. It might be more like a Focus data base, but please don't display it like Focus does.

See (show,) for more specific ideas on this subject.

Actually bit mapped displays and windows are orthogonal issues. I will postpone the factoring until later.

IBM uses the term "APA" or "All Points Addressable" for "bit mapped". The image processing people call these "pixel displays". "Pixel" is short for "PIcture ELement".

The Pixel Window Problem

The problem
There are applications that require direct access to the pixel buffer or at least the performance equivalent thereof. How is this to be reconciled with protected windows? By "protected windows" I mean that one application shall be unable to clobber another or another's buffer by virtue of access to its own buffer. This is not easily reconciled with current hardware where the pixel buffers are in contiguous real memory.

Another problem is to support the updating of windows partially obscured by other windows.

Application's view of Pixel Buffer
The application is provided with a memory key with write access. At the same time it is provided with nominal window information in the form (line count, line length, line stride, pixel size, pixel aspect ratio).

The application counters with values of its own for these parameters. The application can expect better performance insofar as it conforms to these values.

The application stores directly into this buffer and the image appears on the screen soon thereafter.

The real window is padded with an application specified pattern if the real window is larger than the application's window.

If the application does not conform to pixel size or aspect ratio something slow and ugly will be done to conform the application's pixels to the pixels of the real window. This might interact with a user's ability to zoom.

Gnosis segment keepers may be used here to help solve the problem.
We assume here that the application normally remains aware of the real window size and that the line stride of the application accessible pixel buffer may change by mutual agreement between the window manager and the application. The "line stride" is the difference between pixel addresses of successive lines.