portable CLOS window system

[Rob Pettengill <rcp%sw.MCC.COM@MCC.COM>]

    Date: Sat, 8 Oct 88  15:06:52 CDT
    From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
    To: Rob Pettengill <rcp%sw.MCC.COM@MCC.COM>
    Cc: cl-windows@SAIL.STANFORD.EDU
    Subject: Re: portable CLOS window system
    In-Reply-To: Msg of Fri, 7 Oct 88 16:46:04 CDT from Rob Pettengill <rcp%sw.MCC.COM@MCC.COM>

    Rob, can you clarify your characterization of the portable CLOS window system?
    Below, I've tried to show the various interface layers that you mentioned.  What
    exactly do you see as the responsibilities of each layer?  In general, what sort
    of data goes across each interface? In this picture, what exactly is it that we
    should refer to as "the window system"?

    Hi	Application
 .	    ^
 .          | 
 .          V                                       
    .	Application toolkit                           

Here is a pass based on our experiences (positive and negative) with
the DELI Window System ...

The Application toolkits provide:

* A consistent look and feel for the elements in the toolkit library.
Note that the WSII (below) should provide an interface to query for
user interface preferences currently in effect for the window server
and display.  This could include colors, fonts, mouse interaction
style (ie click-to-select, hold-and-release).  This whole area of
window manager / toolkit responsibility and style clash is an
important one to work on.

* Elaborating the functionality of the basic window system gadgets,
while respecting the common protocols established in the window system
layer.

* Providing common low level applications such as editors (text and
figure), graphers, application interface construction tools, ...

    .	Window system interface

The window system (client) interface corresponds most closely the the
normal concept of a window system.  In addition to the primitives of
the WSII, the full window system interface adds an extended event
model, compound windows (window objects that represent collections of
screen windows), buttons, simple menus, viewing transforms, gauges,
sliders, scrollbars ...  As much as possible this layer should be look
and feel independent.  The emphasis is in two areas:

* Fleshing out the WSII functionality into a more useful programatic
interface.  Toolkits could be build directly on the WSII.  The window
system layer gives us a chance to include interfaces for common window
idioms built on the WSII which all tookits will want to share

* Defining the basic programming protocols for window system gadgets
that will be elaborated in the toolkits.  The visual appearance of
gadgets is primitive and neutral, the emphasis is on working out the
interfaces and protocols for interaction between windows and gadgets.
For example: how a scrollbar communicates with the viewing transform
of a window.

This layer will provide both a programatic interface (to use it as it
is) and a class specialization interface to allow customization and
reuse of the window system interace in the toolkit and applications.

    .	Window system-independent interface   ...........................

The WSII implements the window virtual machine interface as a
collection of primitive window system resource objects and operations.
Graphical drawing contexts, coordinate systems, canvases(primitive
windows), fonts, colors, streams, active regions, window system event
handling, and drawing are all defined here.  The WSII has the
responsibility of maintaining consistency between the actual
configuration of windows on the screen and the lisp world knowledge of
those windows.  This will require automatic handling of some window
server events (for example resizing and negotiations with a tiled
window manager).  This layer should be a subset of the full window
system defined in the layer above.  The functions and objects in its
external interface should be specializable.  This layer must be ported
to each new window server interface.

    .	       ^                                 Implementation-dependent
    .          |                                          |
    .          V                                          V
    Lo	Base protocol

The base protocol interface provides communication with a specific
type of window server.  It should provide as efficient an interface as
possible to the basic protocol (ie the X protocol, not xlib, not clx).
The reason for this layer being at a very low level is to avoid
gratuitous differences with the WSII and the need for inefficient
changes in representation.  For DWS Jim Peterson and Glenn Downing
wrote NX (ie Native X interface to X10R4) which was mostly automaticly
generated from the X10 network protocol specification and had only a
very thin veneer of functionality above that.  Basing this layer on
stream communications to a server makes it easy to port to a new
compiler or new hardware.

  Robert C. Pettengill, MCC Software Technology Program
  P. O. Box 200195, Austin, Texas  78720
  ARPA:  rcp@mcc.com            PHONE:  (512) 338-3533
  UUCP:  {ihnp4,seismo,harvard,gatech,pyramid}!ut-sally!im4u!milano!rcp