Re: OBJECT-ORIENTED CLX

[Kerry Kimbrough <Kimbrough@dsg.csc.ti.com>]

I think it's a good idea to have a version of CLX which consists of CLOS classes
and generic functions and which thereby meshes directly with CLOS.  For the most
part, I regard this as matter of implementation.  Very little of the existing
CLX programmer interface ought to change.  One of the few exceptions would be a
slightly different interface for process-event.  But, destroy-window could
remain as an alias for (close-object window), all the accessor names could
remain, etc.

:x-server slots
  I think it's correct not to allocate :x-server slots; the programmer
  should have complete control over where to define client-side caches. What
  about classes for which most programmers would prefer the slots to be cached
  (e.g. fonts, gcontexts)? Perhaps CLX should define both cached and uncached
  subclasses for these.
  
  Why do the cursor and glyph-cursor classes define :x-server slots?  These
  values cannot be inquired via a protocol request.  Same thing is true for
  other classes and other slots (e.g.  background slot of window).  Such slots
  are really just "initargs".  But, if you separate make-instance and
  open-object, then these have to be :allocation :instance. This sorta defeats
  the idea of not allocating copies of server resources; is this an argument
  against open-object?

  The idea is that (slot-value object 'foo), where foo is :allocation :x-server,
  will cause a server request, right? Otherwise, an :x-class metaclass would not
  be necessary. A complication here is CLX's with-state macro. The following
  forms must be equivalent.

	(with-state (window)	  
	  (setf (window-x window) 100)
	  (setf (window-y window) 200))

	(with-slots (x y) window
	  (with-state (window)
	    (setf x 100)
	    (setf y 200)))

	(with-state (window)
	  (with-slots (x y) window
	    (setf x 100)
	    (setf y 200)))

  

Saving CLX objects
  Good idea. But, I'm a little confused by the description. If no memory is
  allocated for :x-server slots, then where do you cache values when the object
  is closed? 

  Certain properties of a window depend on its display connection (e.g. depth),
  so a saved window could only be opened if its display is also opened to
  exactly the same host and display number. Right?



drawable
  parent and border-width are window slots, not drawable slots. BTW, a window's
  slot really ought to be setf'able, with optional new-x/new-y arguments
  (generates a ReparentWindow request)


process-event
  I prefer alternative #3, (defmethod handle-event ((w window-class) (e event-class))).
  As Jim noted, this lets you define extended event types and then use
  handle-event (outside of process-event) to dispatch events uniformly.

  This alternative would be much improved if there actually was a way for CLX to
  dispatch on programmer-defined subclasses *inside* process-event.  It's not
  clear how to implement this.  Another thing is that I've noticed it's
  frequently useful to define a new event subclass procedurally, either via a
  relation predicate over its slots (e.g.  :button-1-press, :shift-button-press,
  etc.) or by a function of the event stream (e.g.  :double-click).  But, CLOS
  doesn't handle these kind of (sub)classes.