[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[York@Chuck-Jones.ILA-West.Dialnet.Symbolics.COM: Re: [(Robert O Schmidt): clim for explorer ii]]

Since Mabry Tyson forwarded my message on this subject, I will forward a
message from Bill York which touches on the same issues.

----Begin forwarded message----
Date: Tue, 23 Jan 90 19:48 EST
From: William M. York <York@Chuck-Jones.ILA-West.Dialnet.Symbolics.COM>
Subject: Re: [(Robert O Schmidt):  clim for explorer ii]
To: N Nagase <nagase@dsg.csc.ti.com>, schmidt@flash.bellcore.com
cc: info-ti-explorer@sumex-aim.stanford.edu
In-Reply-To: <19900123175823.7.HORNIG@SUNDOWN.SCRC.Symbolics.COM>,
             The message of 23 Jan 90 06:41 PST from nagase@dsg.csc.ti.com,
             The message of 23 Jan 90 06:41 PST from N Nagase
bcc: discuss-clim@STONY-BROOK.SCRC.Symbolics.COM

I received a copy of this message earlier today.  While it seems
intended to be a description of CLUE/CLIO features, there is quite a bit
of information (and some confusion) about CLIM which I would like to
briefly address.

    Sender: nagase@foxtrot.csc.ti.com
    Date: Tue, 23 Jan 90 09:41 EST
    From: N Nagase <nagase@dsg.csc.ti.com>
    To: schmidt@flash.bellcore.com
    cc: info-ti-explorer@sumex-aim.stanford.edu
    Subject: Re: [(Robert O Schmidt):  clim for explorer ii]

    I am forwarding the following info.  The information was provided by
    Kerry K.  Regards, Nobi.

    ------- Forwarded Message

    The Standard Lisp Environment (SLE)...

[removed info on SLE]

    CLIM (Common Lisp  Interface Manager)  is a  Lisp user  interface toolkit  being
    developed by International Lisp  Associates.  CLIM is  designed to make  many of
    the features of Symbolics Dynamic Windows portable to different window  systems.
    There are currently no plans for CLIM to be available on the Explorer.

Actually, this is not quite true.  There are no current plans to establish
a CLIM distribution channel through TI directly (as there are with other
Lisp vendors) since TI has done its own work in this area and it is not
immediately obvious how to merge the efforts, either technically or
commercially.  Our CLIM implementation is a portable Common Lisp program
which runs on top of X Windows (among other window systems), and therefore
should be easily ported to the Explorer environment.  If there is
sufficient customer interest in CLIM on the Explorer it will be made

    CLUE and CLIO are designed to  enable the delivery of portable,  well-integrated
    Lisp applications  on  conventional  systems.   CLUE/CLIO are closely integrated
    with the X  Window System  because X  is the  standard user  interface substrate
    found  on  all  delivery  platforms  for  sophisticated  Lisp  applications  ---
    including supercomputers, workstations,  new-generation personal  computers, and
    even Lisp  machines.   However,  CLIM  falls  short  of  these goals for several
      1. Limited power
	     Because CLIM  is  designed  to  be  portable  across  different  window
	     systems, it is  unable to  access the  full power  of any  of them.  In
	     particular, a CLIM program running on  the X Window System will  not be
	     able to use certain X features.

This is almost correct.  Certain of the features of each supported host
window system will not be available to a *completely portable* CLIM
program.  However, the CLIM application designer has the flexibility to
make tradeoffs between portability and integration with the host window
system by making calls to layers below the defined portable interface
(directly to the CLX level, for example).

	     It might  appear  that  the  missing  features  are too "low-level" for
	     anyone  to  worry  about.    But  experience  shows   that  programming
	     sophisticated user interfaces  is complex  and requires  access to  all
	     levels of the system.  While most applications may not need the missing
	     features very often, no access at all can mean significant problems ---
	     abandoning   good   solutions   or   falling   back   on   awkward   or
	     system-dependent work-arounds.

	     In SLE, CLUE and CLIO  are built on top  of CLX but do  not "cover" it.
	     All CLX  functions  are  available  to  application programs.  The true
	     application interface for  UI programming  is CLX+CLUE+CLIO,  with each
	     system providing only those  capabilities not already  present in lower
      2. Lisp-ocentric

CLIM is, in fact, designed to be well-integrated with the Lisp programming
style.  It makes heavy use of language-extending macros and is written in
CLOS.  We consider CLIM, along with CL and CLOS, to be the third leg of the
tripod supporting powerful Lisp applications.
	     Much of what CLIM offers is a look-and-feel environment different  from
	     any other found on conventional delivery platforms.  Based on Symbolics
	     Dynamic Windows, CLIM is a system originally designed specifically  for
	     Lisp programming.   Some  key  mechanisms  of  CLIM user interfaces ---
	     mouse sensitivity, mouse documentation --- do not appear in any of Mac,
	     Presentation Manager, Motif, Open Look, etc.

The presentation-based capabilities of CLIM are only part of the overall
CLIM toolkit.  The heart of CLIM is a portable graphics model (i.e. a
powerful graphics protocol with a "back-end" for each of the supported host
window systems) coupled with a portable event-level input architecture.
The higher layers of CLIM are implemented in terms of this kernel.  In
addition to the stream-oriented I/O and presentation-based modules
mentioned above, CLIM provides support for building "widget"-oriented
applications.  Using the basic input event kernel (and, of course, CLOS)
the application builder can create "widgets" that track the mouse and
handle clicks much like CLUE or Xtk.  CLIM will provide a basic library of
widgets, including buttons, sliders, etc.

We think that by adding the presentation-based capabilities to those found
in the "conventional" UI toolkits mentioned above we are providing power to
the Lisp application programmer.  Lisp has traditionally provided greater
capabilities to its programmers than do the conventional languages.

	     In delivery environments, the level at which look-and-feel distinctions
	     appear in the  application architecture  is chiefly  the component,  or
	     "widget", level --- controls, menus,  dialogs, text editing, etc.   
There are many viable Lisp application delivery platforms on the market
today, only some of which have made X Windows their standard UI toolkit
(for example, 386 PCs running MS-DOS and Microsoft Windows).  Therefore,
there is another aspect of look-and-feel portability:  the ability to
produce output to (and manage input from) a multitude of host window
systems.  The key goal of CLIM is to support application delivery on every
viable Lisp platform.  CLIM currently supports four native host window
systems:  X Windows, Microsoft Windows, Macintosh (QuickDraw), and Genera.
CLIM's architecture supports the addition of others, including Display

	     the component level is barely discernible in the CLIM architecture.  It
	     is therefore unclear how a CLIM program can play the look-and-feel game
	     of its delivery environment, much less how it can do this in a  fashion
	     portable to many different look-and-feel environments.

Application programs written in CLIM are automatically portable to all
supported environments.

	     CLX and CLUE are base mechanisms that are "policy-free"; that is,  they
	     can be used to implement any  look-and-feel.  CLIO represents a set  of
	     components which are implemented to conform to a standard look-and-feel
	     style  guide.    But,   the   programmer   interface  is look-and-feel-
	     independent.   This  means  that  an  application  can  adapt  to   the
	     look-and-feel that  appears  in  the  delivery  environment  simply  by
	     changing the CLIO implementation used.

CLIM's application interface to "widgets" or "components" is via a defined
protocol of CLOS generic functions.  The actual look and feel of a given
widget is independent of this interface and is determined by the widget
library implementor (who may choose to implement an industry standard such
as Motif or may choose to implement non-standard, idiosyncratic widgets).
In addition, the CLIM widget architecture supports the use of existing
widget libraries provided by the larger host environment.  As another route
to look-and-feel integration, CLIM defines an "Adaptive Toolkit" protocol
that allows the Lisp application program to directly use widgets from the
native (typically non-Lisp) host window system toolkit.  (This means that
instead of, for example, writing a Motif-conforming widget toolkit entirely
in Lisp, we can leverage off the work being done by the scads of C
programmers at OSF.)

      3. Architectural Oddity

	     The CLIM architecture evolved from the peculiar world of Lisp machines,
	     and in many ways it is out  of step with current UI programming  models
	     used elsewhere.

Naturally, we prefer to think of CLIM as extending those models by adding
additional capabilities taken from the Lisp community at large.  The
"peculiar world of Lisp machines" has produced quite a few substantial
advances over the years (CLOS was heavily influenced by Flavors and Common
Loops).  We hope that, as was the case with object-oriented programming,
the ideas in CLIM will eventually find their way into the UI programming
models available in more conventional environments.

	     The  CLIM  architecture  defines  layers  both  at  a  high  level   of
	     abstraction   (e.g.     command    processor,    presentation    types,
	     accept/present) and at a low  level of abstraction (e.g.   graphics and
	     window system interface).  However,  certain intermediate levels  (e.g.
	     components, or widgets)  are not  well-defined.  Some  of the resulting
	     problems with  look-and-feel  integration  were  mentioned  previously.
	     Another drawback is that important  tools in the larger  UI development
	     environment need  to  operate  at  the  widget  level  --- for example,
	     interactive UI construction tools such as Action!, GUIDE, and UIMX.

	     CLIM tends to draw upon a model of interaction that is synchronous  and
	     based  on  typed  commands.    However,  modern  user   interfaces  are
	     asynchronous, are based  on a  uniform event  stream uniting  all input
	     devices, and  are  oriented  toward  graphical  interaction  instead of
	     typing.  Of  course,  this  is  not  to  say that a graphical interface
	     cannot be implemented in CLIM.  But  many features of CLIM ---  command
	     processor, accept/present --- act primarily to enhance a user's ability
	     to "type in" one command at a  time, possibly using pointing as a  kind
	     of shorthand for one or more arguments.

It is possible that Kerry hasn't seen a recent version of the CLIM
specification (copies publicly available soon), because he fails to
accurately characterize CLIM's model of interaction.  CLIM's input kernel
is, in fact, fundamentally event oriented, providing both synchronous and
asynchronous handling of input events.  Individual applications may choose
to have their own processes and operate in a stream-oriented, synchronous
(queued) fashion.  On the other hand, it is possible to implement a
completely asynchronous "control panel"-style application in which the
application's "operations" are invoked via the widget callback mechanism.

CLIM has no inherent bias towards typed commands.  A CLIM application
defines a set of "operations" with typed operands.  The substrate uses this
specification to support a variety of user interaction styles.  The
interaction style may be entirely mouse driven, keyboard driven, or a
combination of both.  Application programmers are free to implement new
interaction styles.
----End forwarded messages----