[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>,
<2842094478-3535316@Foxtrot>,
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
available.
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
reasons:
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
levels.
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
PostScript.
But
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----