X & self

[trost%reed.BITNET@Forsythe.stanford.edu]

Folding Xlib into Self sounds like a not-too-clever idea --- all the
sudden you'd have to worry about X memory allocation and all that
silliness.  Self already supports TCP communications, so writing a
Self version of Xlib is probably simpler (and you'd rather write Self
code anyway, right? :-) ).

And no, I haven't started working on it yet -- one of my Things to Do :-).

Though I suppose I ought to foist *my* views onto the world while I
have the chance....

First, one probably wants to avoid putting the prototypical X display
at the top level; i.e., things should be arranged so that "display" is
not a parent of "x", so that you have to say "x display clone" instead
of simply "display clone" -- this namespace division should prevent
confusion with different window systems (like the Self builtin
system).

Windows should have their display (screen?) in one of their slots --
avoids passing the display all over the place.

To create a window, you shouldn't have to clone a window -- you should
send a message to the window's intended parent to create the window.
Querying the display (or actually, a screen on the display) will give
you the root window.

Implementation should probably proceed in two layers -- "traits x"
could have a slot named "primitive" which would contain the very basic
protocol-conversion information.  More sophistication (like buffering
of requests) could then be implemented at the higher level.

Just my ideas...any comments?