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

CLIM info

Recently we've had a few notes about CLIM on the SLUG mailing list.  The
following information also seems pertinent.  It originally appeared on
the TI mailing list.  (I've received okays from both Nobi Nagase and
Scott McKay that this could be forwarded to the SLUG mailing list.)

Mabry Tyson

    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...


      ------- 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

		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

	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
    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
    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

    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
    CLIM is also working under Symbolics' implementation of CLOS, which is a
    high-performance implementation for Genera and for CLOE.

    ------- End of Forwarded Message