Needed: Info on LISP X based toolkits

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

In the spirit of Stan's posting, I'd like to toss in my two bits
worth.  First I want to applaud the MIT X Consortium (CLX) and TI
(CLUE) for making their systems available to all of us to examine and
use.  Even though these are good designs that do many things well,
there are issues that are not well addressed in those designs.  I base
my comments on my imperfect understanding of CLX, CLUE, the
Schlumberger Generic Window System, several years experience with the
lisp machine window system, and on the design of a portable CLOS based
window system.  

Here at STP/MCC we have written an object oriented window system
client interface in CLOS.  We have a reasonable object oriented
toolkit including menus, buttons, choicers, gauges, sliders,
scrollbars, composed windows, a powerful grapher, and an interface to
a multi-window Gnu emacs server that makes emacs appear as an embedded
editor to common lisp applications.  The DELI Window System, DWS, is
part of an application prototyping platform developed for internal
use.  This is all in an early alpha stage (and will hopefully
eventually be available from one of our shareholders or MCC).

I believe that some of the considerations that influenced our design
are of general interest in the consideration of a portable standard
common lisp window interface.  I will try to summarize these here
(colored by my own biased recollections, and the comments of others at
the CLOS workshop ...).  Hopefully some of these will provide good
fodder for discussion.

1.  The interface should not depend on a particular window system
protocol.  Just as file streams are independent of the network protocol
(nfs, nfile, qfile, ...) the same portability is desirable in a window
system interface.  X is wonderful because it will be available on so
many different types of hardware; however I hope that we have even
better protocols in the near future.  For example: X is bit mapped
oriented.  I expect that before long, powerful display list oriented
graphics capabilities, like those found on the Silicon Graphics IRIS,
will be standard equipment on many workstations.  Protocols like NeWS
or Display Postscript will allow applications to take much better
advantage of this hardware.

2.  The interface can be made portable by defining an internal window
system independent layer which can be used to retarget the interface
to multiple window systems.  This layer should not be a greatest
common denominator, since this approach leads either to an interface
tuned to a particular target or one that performs poorly for all
target window systems.  The interface should be designed at a high
enough semantic level so that "intent" is expressed rather than
"procedure" for the most common user interface idioms.  

For example concepts such as coordinate transforms, object and region
selection, and object dragging could be supported by the interface.
This means that more work will be required to implement the interface
for "dumber" window servers, however it will be easy to exploit the
capabilities of more sophisticated displays.  For example object
dragging could be simulated by XOR redrawing of a bounding box on a
low performance display, bit-blitting a pixrect on a pixel oriented
device, or translating a display list on a display list engine.

The DWS uses a Window System Independent Interface, WSII, that is at a
roughly intermediate level between the X10 and NeWS protocols.  The
WSII was originally written for X10R4 and has been retargetted to NeWS
and the X11 (using CLX!) protocols.

Perhaps the ideas behind the CLOS Meta Class protocol can be applied
to produce a more flexible window system interface standard.

3.  Although the window system interface on which application toolkits
are built should definitely be object oriented, there is no strong
need for the WSII layer or the specific protocol drivers (CLX) to be
object oriented since they are not exposed to the applications.  We
want these to be the fastest way from lisp to the window server.

4. The availability of network window servers requires new "rules of
the road" for cooperative network window system use by applications.
The window system interface should provide support for "network
friendly" applications which do not make assumptions about the display
device, the window manager, the relationship of the hardware executing
the application to that displaying the application, or what other
applications may be trying to share the display space at the same
time.  For example "display grabbing" beyond the scope of windows
owned by the application should be avoided.  

It should be possible to build "meta applications" that are composed
of several individual applications running in different hardware
environments.  These meta applications could be controlled from a
single display terminal and their heterogeneous composition invisible
to the user.

5. Ideally the "look and feel" of the application would defer to that
selected by the user on his workstation display.  The ability of many
X applications to run under many different tiled and overlapped window
manager illustrates the direction we should take.  The window system
interface should be prepared to provide window management functionality
where none exists, but should gracefully defer to window defaults and
management present on the selected window server.

6. In CLOS Common Lisp has the most powerful object oriented
capability of any language today.  A standard window system interface
should provide a standard interface for sub-class specialization as
well as the normal standard instance interface.  The sub-class
specialization interface should allow toolkit and application
developers make full use of CLOS capabilities such as multiple
inheritance and specialized meta classes.  This additional interface
will allow for much greater leverage in the reuse and customization of
classes and methods in application toolkits without compromising
portability.

Well I've probably run on enough for today.  DWS only goes a small way
toward meeting these goals - I'd love to be able to buy a vendor
supported window interface that met most of them (and the important
stuff I've forgotten or don't know yet) in a year or so.  I am curious
how my priorities rank with those of others; so I hope we keep this
discussion rolling.

;rob

  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