nagase@dsg.csc.ti.com (N Nagase) (02/02/90)
FYI. I had no intention to make this subject a controversial issue,
but I feel that Mr. McKay's message below needs to forwarded to those
who have read the original Kerry's message. Since Mr. McKay
has given us the permission to distribute a wider audience, here it is:
I believe Mr. McKay explains very well on some of the issues that Kerry
had pointed out.
Constructive messages are welcome, but let's not debate over it...
Regards,
Nobi
------- Forwarded Message
Date: Tue, 23 Jan 90 16:52 EST
From: Scott McKay <SWM@SAPSUCKER.SCRC.Symbolics.COM>
Subject: Re: [(Robert O Schmidt): clim for explorer ii]
In-Reply-To: <2842094478-3535316@Foxtrot>
Date: Tue, 23 Jan 90 08:41:18 CST
From: N Nagase <nagase@dsg.csc.ti.com>
I was attempting to compose a detailed message to answer Mr. Schmidt's
questions, but some inaccuracies in Mr. Kimbrough's reply (as forwarded
by Mr. Nagase) need to be addressed. It is understandable how these
inaccuracies might arise: the CLIM specification currently publicly
available is out of date, and even the most current CLIM specification
glosses over some of the areas which Mr. Kimbrough alludes to. All of
the people working on the CLIM specification and implementation are aware
of these omissions, and we are working actively to address them.
You may feel free to distribute this to a wider audience.
------- Forwarded Message
The Standard Lisp Environment (SLE) offers a broad range of tools for creating
object-oriented, graphical user interfaces based on the X Window System. SLE is
a standard software platform for developing portable Common Lisp applications
for the Explorer and other Common Lisp environments.
Many of the SLE components for user interface programming appear in Release 6.0.
CLX The basic Common Lisp programmer interface to the X Window
System.
X11M An X server for the Explorer monochrome display, compatible with
X Version 11 Release 3.
CLUE A toolkit for creating user interface objects using CLX and
CLOS.
Future enhancements planned for SLE include CLIO, a set of classes that
implement many common user interface components, including buttons, menus,
scrollers, dialogs, text editing, image display, etc. An important aspect of
CLIO is that it defines a programmer interface to these components that is
independent of their "look-and-feel". CLIO allows a program to be portable
among different standard look-and-feel environments, including Open Look, Motif,
and Macintosh. Also planned for SLE are CLOS-based tools for creating and
interacting with hierarchies of graphical primitives such as lines, polygons,
curves, and text.
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.
It is true that CLIM is an intellectual successor to Dynamic Windows and
that it the intention of CLIM to include many of the features of DW.
However, it is explicitly not a goal to just make a portable version of
DW, since a number of things in DW have since proven to not be portable
(or are out-and-out bad decisions or mistakes).
There will, of course, be conversion tools and macro packages to ease
the transition from DW to CLIM.
There are currently no plans for CLIM to be available on the Explorer
So far as I know, this is true. Note that CLIM will almost certainly
work on X Windows running on Explorers.
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:
In fact, CLIM does not fall short of any of these goals, although the
state of the current specification might lead one to believe that CLIM
does fall short.
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 not so. At any time, a programmer using CLIM can directly call
X features. However, doing so trades off against strict portability.
That is, once a programmer calls an X-specific feature, his program is
no longer completely portable to, say, MS Windows.
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.
Exactly so, which is why CLIM does not interfere with access to lower
level window system features.
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.
This statement applies to CLIM as well, except that, right now, the
interface for UI programming is CLX+CLIM. (Note that it would be simple
to write a CLUE back-end to CLIM!)
2. Lisp-ocentric
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.
Right now, CLIM implements some of its own look-and-feel, which is indeed
based on the Dynamic Windows look-and-feel. The historical reason for
this is that the people designing and implementing CLIM are most familiar
with the DW look-and-feel, and understand those issues best.
However, that will not remain the case for long. CLIM's design includes
an adaptive toolkit interface (we sometimes call it "chameleon mode") in
which it directly uses the underlying "widgets" of the toolkit CLIM is
hosted on. That is, in chameleon mode, CLIM menus have the exact
appearance of, say, OpenLook menus because they *are* OpenLook menus.
Mouse-sensitivity does exists on others UIMSs, so Mr. Kimbrough must be
referring to highlighting. CLIM can provide highlighting, which gives
the user immediate context-sensitive (semantic) feedback. CLIM can also
provide mouse documentation. These features need not be used, but they
are an extremely valuable bit of additional functionality for any
complex user interface, as anyone who has used Symbolics or TI lisp
machines can attest to.
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. 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.
CLIM intentionally hides the component level except when the user decides
that he wants to get to that level of detail. The component level can be
accessed via things called that are tentatively named "views". The CLIM
specifications which Mr. Kimbrough has probably seen are silent on this
issue, and that is why it is "barely discernible". The specification now
being worked on explicitly addresses the widget level.
Things like dialog and menu layout are, by default, handled automatically
by CLIM. Think about it: for the most part, laying out menus and dialogs
by directly speaking about all of the widgets which comprise the menu or
dialog is just so much busy work. If the UIMS does that for you, then
you do not have to do it yourself. Naturally, if you want to lay out
menus and dialogs yourself, you are free to.
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.
Ultimately, CLIM allows you to access the look-and-feel of the window
system toolkit it is hosted on. The programmer interface to CLIM is
also independent of look-and-feel.
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.
Actually, the CLIM architecture is only out of step with current UI
programming models insofar as it is ahead of them. If you read Gene
Cicarelli's MIT Master's thesis ("Presentation Based User Interfaces",
MIT AI-TR 794), or in recent work by Pedro Szekely or Dan Olsen, or in
the paper "A Presentation Manager based on Application Semantics" (by
myself, Mike McMahon and Bill York), or in any of the papers in which
Brad Myers mentions the difficulty of doing good semantic feedback, you
will see that my claim that CLIM is ahead of most everything else is not
just an idle boast. I can forward some of these papers to you if you
would like.
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.
As I said above, the publicly available CLIM specifications are
incomplete with respect to the widget level. Mr. Kimbrough is right
that interactive UI construction tools are important, and you can rest
assured that CLIM will be more than adequate to support such tools.
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.
(First an aside: most of the event-loop model UI toolkits are
traditionally used in a synchronous manner. Nearly every Mac application
I have seen and many X applications are synchronous, except for a small
class of UI objects best called "panic buttons". In any event, CLIM also
is implemented based on a "uniform event stream uniting all input
devices", so synchronous vs. asynchronous is a red herring.)
It is incorrect to think that CLIM is oriented toward typing. In fact,
ACCEPT and PRESENT provide for transparent, mixed-mode user interfaces
which support typing as well as pointing devices. In such a mixed-mode
style, a user can use a pointing device (such as a mouse) to accelerate
the typing process, or he can use the mouse as the only input device.
By the way, CLIM's command model has very little to do with typing. A
"command" is merely an interface to some operation in the application;
the "command" specifies the types of arguments that the application
operation wants to see. A "command" says *nothing* about the interaction
style; it is perfectly reasonable to have a completely iconic, direct
manipulation user interface implemented entirely in terms of commands,
ACCEPT and PRESENT. In fact, I have written a number of such
applications myself which have non-trivial direct manipulation user
interfaces.
What Mr. Kimbrough has not mentioned is the most important aspect of
CLIM, namely, that it provides excellent semantic integration with the
underlying application (via "presentation types"). All user interface
interactions are expressed in terms of semantically typed objects rather
than in terms of widgets. In addition to being a very concise way of
expressing a user interface, complete UI consistency is gained for free,
and obeys the usual object-oriented model of behavior inheritance.
Traditional (or archaic, if you prefer) command-line interfaces can be
expressed via presentation types, but highly interactive direct
manipulation interfaces actually even simpler in the presentation-based
UI model. Dialogs in particular are also very easily specified using
presentation types. The paper "A Presentation Manager Based on
Application Semantics", which can be found in the proceedings of UIST
`89, explains this quite well.
------- End of Forwarded Message
To reply to and elaborate on a few points make by Mr. Rice. Points I
have nothing to add to I simply omitted; I hope that I have in no way
twisted your intention.
- CLIM is intended to be portable, providing an abstract
interface to high-level window operations.
CLIM provides an abstract interface to UIMSs, not just to window systems.
- CLIM is claimed to be a window system (as opposed to a
low-level windowing protocol (like X). It's supposed
to have the following characteristics amongst others:
CLIM is a UIMS, not a window system.
- From the above you will see that it looks like they've
reimplemented a large slice of the Genera window
system. This is not entirely surprising, since a
number of ILA's people are ex-Symbolics employees.
As I said above, CLIM is the intellectual succesor to Dynamic Windows,
not simply a portable reimplementation of the same old stuff.
- CLIM is supposed to work on the native machine's
windowing substrate. They have an X version that
apparently works on random unix boxes running X, a
Quick-draw version, a Symbolics version and an MS
windows version to run with the 386 Symbolics product.
This is correct.
- Eventually they plan to have a portable interface to
things like dialog boxes. This is intended to give the
look and feel of the underlying window system for free.
This is correct.
- There is no grapher. In fact they will not be selling
any program development tools (yes, I know a grapher is
a user tool too). This is because of an agreement with
the hardware and LISP vendors, each of which would like
to be the best CLIM development environment.
There is a grapher running under CLIM as of Novemeber.
- CLIM runs under PCL on their sundry implementation.
Current versions run under the Victoria day release,
though they claim that they are working closely with
Gregor to make it work with the next up-and coming PCL
release.
CLIM is also working under Symbolics' implementation of CLOS, which is a
high-performance implementation for Genera and for CLOE.
------- End of Forwarded Message