[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: OBJECT-ORIENTED CLX
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.