[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Xl1200 as x server

    Date: Thu, 2 Aug 90 18:55 EDT
    From: miller@GEM.cam.nist.gov (Bruce R. Miller)

	Date: Thu, 2 Aug 90 17:35 EDT
	From: Barry Margolin <barmar@Think.COM>

	    Date: Thu, 2 Aug 90 14:23 EDT
	    From: miller@GEM.cam.nist.gov (Bruce R. Miller)

	    Just how does  this work  (for the  X naive)?

	It's all done through the magic of object-oriented programming.  ...
    Well, I didn't mean That naive ! :>  (but thanks anyway)

Well, someone else who is may have been too embarrassed	to ask.

    What I had in mind was the following:

    Not knowing the X protocol, it  is not inherently obvious that  the full
    protocol used by  TV and  DW CAN  be (practically)  translated into  the
    appropriate X.  That is to say, although equivalent functionality  could
    most likely be achieved in X at some level in the application, the TV/DW
    protocol has been decomposed into certain operations, some of which  may
    have no equivalents.   Take some random old TV-style application and  it
    is throwing all  sorts of  random messages,  high-level and  low, at the
    window-stream.  (I  mean,  can  you  honestly  say that TV:windows HAD a
    protocol? You  and  I  both  have  spent  LOTS of time figuring out what
    messages were sent and who handled which parts in which order, before we
    were `saved' by  DW! "Lets  see, If  I put  my-mixin right  here between
    tv:window-with-foo-usurped-but-no-scrolling                          and
    tv:stream-input-from-kludged-borders-mixin, and  define  a  whopper  for
    :update-vsp-for-changed-borders (hmm, what's the argument list), it  just
    might work") For it to work in X, ALL those messages have to be  handled
    by the X stream.

Most of the X functionality is spliced in at a level that even wizards
(except the ones who had to redesign it so that this would all work)
rarely play with (the only time I played at this level was to implement
key-click, and it doesn't work in Genera 8.0).  It's at the screen and
console level, not the window level (the virtual console is a single X
window, with Genera managing the windows inside it), so none of those
funky window mixins are affected by it.  DW is completely unaffected as
well, because it doesn't exist at this level.

The set of operations one can do on a screen or console is much smaller
than the operations that can be done on a window, and they map pretty
straightforwardly onto the X protocol.  It's basically just drawing
lines and shapes, filling regions, drawing characters, and accepting
keyboard and mouse input.

An analogy from a more common communication environment is ASCII
terminals.  Going from an ordinary Lispm console to an X terminal is
like going from a hardwired terminal to one connected by a modem.
Programs that just send and receive ASCII don't care what kind of wire
it goes over.