Re: LISP X based toolkits

[System Files <SYS@SAIL.STANFORD.EDU>]

Received: from ti.com by SAIL.Stanford.EDU with TCP; 6 Oct 88  19:08:51 PDT
Received: by ti.com id AA22384; Thu, 6 Oct 88 21:06:07 CDT
Received: from dsg by tilde id AA00678; Thu, 6 Oct 88 19:37:40 CDT
Received: From Sierra By dsg Via CHAOS-NET With CHAOS-MAIL; Thu, 6 Oct 88  19:37:13 CDT
Message-Id: <2801176696-7616461@Sierra>
Sender: KK@Sierra.csc.ti.com
Date: Thu, 6 Oct 88  19:38:16 CDT
From: Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>
To: Warren Harris <harris%hplwhh@HPLABS.HP.COM>
Cc: cl-windows@SAIL.STANFORD.EDU
Subject: Re: LISP X based toolkits 
In-Reply-To: Msg of Thu, 06 Oct 88 00:15:45 PDT from Warren Harris <harris%hplwhh@HPLABS.HP.COM>

   > Adopting a full level (3)
   > would pretty much leave (2) obsolete, and since level (3) would then have
   > to be at least as powerful as (2), we would consequently be programming to
   > just a different version of (2).  This argues for the (2.5) (CLUE)
   > approach.

Bingo. Exactly our rationale.


   > I'm not saying the concept of a Common Lisp User
   > Environment should be eliminated, but we should rethink what we mean by
   > supporting various levels of a window system.  I think this means providing
   > a set of classes which understand both the X server and the necessities of
   > CL (such as streams), and a means of extending these classes when
   > *necessary*.  

CLUE's interactive-stream contact is a stab at this.  Here, the idea is that there
exists a *special* kind of window which can act just like a CL-standard char
stream, as an arg to read, write, etc.  But not every window is a stream.  From
time to time, I seem to hear the notion that all window are streams, that
"stream" is the all-encompassing metaphor.  But this has always baffled me.


   > For one, the degree
   > to which CLUE is object-oriented is completely ad hoc... 

Absolutely correct.

   > (Was this in the name of efficiency or what?)

No. Merely a practical matter of minimizing the "bastardization" of off-the-shelf
CLX. A matter which I'm certainly willing to reconsider.


   > Finally, the notion of callbacks seems more like a throwback to C to me.
   > Perhaps this is what Lanning is alluding to in his comments about the
   > XToolKit.  Why aren't these callbacks generic functions which can be
   > overridden or inherited by subclasses of the class for which they're
   > defined?  That would seem cleaner and more straight forward to me.

The idea is that a callback is instance-specific behavior, not class behavior.
That is, every instance of a given class of UI objects has a unique set of
application semantics, which is represented by its callbacks.  Further, the
application semantics of a contact instance is defined by the application
programmer and is *unknown* to the contact programmer who defines the contact
class behavior.

You can also imagine other ways of packaging callbacks.  I suppose that in CLUE
we opted for maximum flexibility because we weren't willing to claim that we
knew the "right" way to structure the callback interface.  For example,
sometimes a callback communicates with the application, and sometimes it
communicates with some other object in a structured UI.  Sometimes, the
application wants to know which contact is reporting; sometimes it doesn't care.
Sometimes the contact knows all the data to return; sometimes the application
wants to attach extra data.  Sometimes the application wants to define semantics
for a contact action; sometimes the application finds it convenient to ignore
the action.  Sometimes the application consists of objects and callbacks will
invoke their methods; but sometimes not.  Sometimes you're building up both the
UI and application together; sometimes you're slapping a new UI on an existing
set of application functions.  Etc.
 
One rightful objection to the way CLUE works is that invoking callbacks involves
a look-up that is a lot like method dispatch, so why does it have to be
different?  Another approach has recently been pointed out to me.  Instead of
looking up a function associated with a 'callback-name, the contact calls the
generic function 'callback-name.  The application programmer defines a
instance-specific method for 'callback-name by using an (eql <instance>)
specializer.  The method would be created dynamically by using something like
(make-instance 'standard-method ...  :function #'application-function-closure
...) and add-method. Why didn't we do this? It didn't occur to us until now! Hey,
10-4 on that CLOS learning curve.  Anyway, I'm looking into this, and I'd
appreciate any advice on its pro's and con's.


   > I'm sorry if the flames are hot.  

No problem. I like the fire, not the cold.