CLUE and CLX

[Robert Scheifler <RWS@zermatt.lcs.mit.edu>]

    Date: Thu, 06 Oct 88 00:15:45 PDT
    From: Warren Harris <harris%hplwhh@hplabs.hp.com>

    As an aside: I never understood why CLX didn't use the same
    naming conventions as Xlib.

I'm not sure exactly what you mean by "the same" here.  We wanted the
CLX stuff in it's own package, and it didn't seem to make too much sense
to me to put in a redundant prefix "X" (e.g. xlib:x-create-window).
Also, Xlib uses CapitalizationToDistinguishWords, and the general CL
convention is-to-use-hyphens, and CLX follows that convention.  The CLX
interface was largely defined "ignorant of Xlib", so as to keep an open
mind about how it should be structured.  After the fact, we did do a
comparison, and my recollection is that they are reasonably close.  But,
I think CLX kept a little closer to the names used in the protocol spec,
whereas Xlib kept a little closer to names that were used in X10.

    On the contrary I
    would like to see some of Xlib's concepts eradicated from CLX.  An example
    is the distinction between font and font-info structures.

There are no font-info structures in CLX, in case someone was confused
by an implication here.

    I believe CLX should be modernized to the point of embracing
    object-oriented programming.

I would be interested in understanding more specifically what you have
in mind.

    If it really meant what it said about the various levels in a
    window system, why didn't it just pass around X id's as integers?

The only reason Xlib doesn't pass around an "object" for a resource is
because of garbage collection problems.  Early Xlibs (previous versions
of X) went back and forth on this one, trying to do what CLX does but
failing due to the C environment.  The bundling exists because it is
very convenient.

    CLX programmers actually get handed these ids in
    event-handler routines.

Yes, there were efficiency arguments here, perhaps inconsequential ones.

    They don't tell you what to do with them thought
    (like how to lookup the associated xlib:window object).

The CLX doc does tell you to use make-window to perform this mapping.

    Perhaps the primary consideration in the back of the CLX implementors heads
    is that of efficiency -- will object-oriented programming slow down CLX too
    much?

That wasn't the motivation.  Partly it was an issue of whether a single
object system was sufficiently stable and standardized to be able to
make it a requirement (the answer seemed to be No).  Also lurking around
was the notion of being able to use essentially the same interface in
other lisp dialects.  Also, it wasn't at all obvious that we could
quickly reach consensus on what an O-O CLX should look like (in terms of
raising CLX to a higher level).  And, it wasn't at all obvious that CLX
should show through at the higher level (all the issues you enumerated).

    Since CLUE goes against Scheifler and McMahon's original considerations
    about encapsulating the lowest level of the window system, I'm curious what
    they think now that it seems to have caught on.

I have too many flowers blooming right now, and I have a hard time
keeping up with all the details of all of them.  I do not consider
myself a Lisp/OOPS expert in the same league as many of the rest of you
out there; I'd much rather have you experts combine forces to produce
the right thing.