Re: OBJECT-ORIENTED CLX

[kempf@SUN.COM]

General Comments
----------------

CLX may be the wrong place to CLOSify. Pushing CLOS into the 
Common Lisp kernel is a better long term solution in my opinion, if making the
low level interface to windows should be object oriented. This would
have the additional effect of allowing extensibility in other things,
like pathnames. For example, it would be nice to be able to extend
pathnames so that edit buffers could be used. That way, streams could
be opened on edit buffers without special machinery. Windows could benefit
as well.

A better short term solution is a host window system independent object-oriented
layer which targets to X via CLX as one option. Since there are other window
systems out there besides X (e.g. Coral Common Lisp runs on the Mac and targets
to the Mac window system), and, indeed, others may come along in the future,
it would rather seem more approprate to provide a "window virtual machine"
which abstracts away from the underlying host window system as much as
possible. This would isolate Lisp applications from the host window system,
and would fit more in with the general nature and philosophy of Lisp as
an abstraction away from the machine. The "window machine", in this case,
is X.

Specifics
---------

>In
>particular, a new meta-class is defined, X-CLASS, which makes convenient
>the specification of objects allocated external to the Lisp process (in the
>X server).  

This new metaclass is a good idea, but why restrict it just to X? Why not
have a DISTRIBUTED-OBJECT metaclass?

>In this meta-class, a new slot-descriptor is defined,
>X-SLOT-DESCRIPTOR, which allows an additional strategy of allocation,
>namely :X-SERVER.  Specifying :X-SERVER allocation does not reserve space
>in the actual CLOS object for the value, but instead defines reader and
>writer methods which actually perform the X protocol requests.  (There may

I don't understand why this is needed. This could be done with an
X-SERVER-MIXIN which is mixed with all the Lisp classes representing
X objects, then defining the appropriate qualified methods on the
slot accessor functions to perform the protocol requests. Is performance
a concern? If so, then won't the round trip server time dwarf the
amount of time needed to do the qualified method invocation?
My understanding of X is that the types of resources in the server
are not extensible. If so, then the qualified methods for slot access
can be defined and delivered as a nonextensible interface. So the
flexibility of a metaclass isn't needed.

>One difficulty with the old CLX model is that some objects are created in
>the server process simultaneous with their creation in the Lisp process.
>This includes WINDOWs, PIXMAPs, COLORMAPs and CURSORs.  Other objects are
>created in the server process some time after their creation in the Lisp
>process.  This includes DISPLAYs, and FONTs.  This object-oriented
>version of CLX takes the uniform approach of delaying the creation of all
>server allocated objects until the OPEN-OBJECT generic function is called.

This will solve the problem of object creation, but it doesn't solve the
problem of co-ordinating asynchronous state changes in the client and server. 
This is a general problem with programming using distributed objects. 

>(Note: the way
>this works is that while a window is open, all :X-SERVER allocated instance
>variable accesses go through the X server.  When the window is closed, the
>values of these slots as they currently exist in the server are re-cached
>in the lisp objects before the server object is actually destroyed.  That
>way, the next time the window is opened the state is remembered.)

OK, now I understand how you propose to solve the cache consistency problem
between client and server-by simply not caching any state in the client!
Hmmm. What about performance? Having to go round trip to the server just
to figure out the height of a character in a multifont display could
slow display of a complex multifont view to a crawl. 

>	2. It allows the objects' states to be remembered between Lisp
>	sessions.  
>
>This second point is a significant advantage since Lisp images can
>typically be stored on disk via some SAVE-WORLD command.  Lisp images with
>saved CLX objects can then be recreated numerous times.

This is certainly an advantage, but an easier solution is to modify 
the underlying CLX functions to do this. To me, the fact that
they don't do this already is a bug in CLX. This is not an inherent
advantage of your design.

>1.  By defining one event handler method for each type of event.  Each of
>these methods would do a single dispatch off of the type of window.  (This
>was the approach taken by Xenon.)  The dispatch which invokes the method
>corresponding to the event type is handled by magic inside PROCESS-EVENT.
>  ...
>I recommend alternative 1.

This is way too inflexible. Event dispatch is not extensible, except by
subclassing windows.

>3. The final approach would be to define actual event classes and dispatch
>off the window instance and the event instance.  (I believe XCL took this
>approach.) 

This sounds like the right approach. Now, both window classes and event
classes are extensible.

>One question with this approach is how to map out this event hierarchy in
>lisp.  The X11 server doesn't really make any use of the hierarchy, and the
>user may be fooled into thinking that subclassing an existing event class
>would magically begin being utilized by CLX.

If the event dispatcher is not chained to the X server, it may be possible
to define events inside Lisp which have nothing to do with the X server.
For example, one event might be VIEW-CHANGED, which would be used
by a Model/View/Controller type application framework to allow a model
(which may even be in a separate Unix process) to notify its views that
they should update themselves. By isolating event dispatch in one 
place, multiprocessing code is reduced (for those Lisps which have
multiprocessing), thus reducing the need for concern about race conditions
and deadlocks.

>Another disadvantage to this is that generating CLOS objects for each X
>event can be very expensive.  Although using resource caches is possible
>this still seems to be more trouble than its worth.

One or a few event objects per event type is not unreasonable. 

Thanks for you ideas.


			jak