Conference bulova::decw_jan-89_to_nov-90

Random chance is what determines the color(s)...  There's an XOR operation
on the display memory taking place, and you often end up with left-over
colormap entries being referenced.  So the colors depend on (a) what's
underneath, (b) what applications have run before, (c) the phase of the
moon, (d) etc. etc. etc.

	paul

Right.  Before someone else says it, not much of a way to run an airline (or
whatever), but there is no way to do it sufficiently efficiently (good luck
saying that out loud) via the X protocol.  We probably need to invent an
extension protocol request which will do it locally.

UIS does it at the driver level...it saves away the data under the "halo" and
draws two contrasting lines side-by-side, thus guarnateeing that you can see it.

Burns

    This is a serious question. The window border is drawn just inside
    the window so as to provide contrast.  Why not do the same when
    a move is occuring ?   Or do it like UIS ?
    

    
    Hmmm sounds like a chance to see just how good X11 and applications
    are at damage control... how about creating 4 long thin windows that
    are a couple pixels wide with no window manager additions like border
    and banner... that's what UIS does (or something like it).  Then the
    colors are predictable, but applications will need to repair themselves
    very efficiently.
    
    *or* how about if the window manager does a grab of the server, writes
    the screen to a pixmap *then* does the above handling all the expose
    events itself (don't off hand know how, maybe transparent window over
    the entire screen to intercept them?) and repairing the screen from it's
    pixmap.
    

To answer .3, (first part), the problem is damage control.  When you move
one thing over another, you must be able to restore the original quickly.
XOR does that.  With complete windows, you have to notify the client to repaint.
This does not happen fast enough to track a mouse.  As to "the way UIS did it",
UIS is kind of funny on a GPX.  A large part of the windowing system is built
into the driver.  The driver understands about windows, pointer following,
and a whole host of other things.  This has advantages, but also serious
problems.  In DECwindows, the server understands windows, the driver does not.
In addition, there is no protocol request that says "drag this box".  That means
there is no way for a client to tell the server to do box-dragging even if
the capability was in the driver.  That is why I said that maybe a protocol
extension is in order.

Burns

    
    Is the preceeding information still true in DECwindows V2?
    
    If so, does anyone have any hints or tricks to get the color set to
    something specific (or at least something other than black)?
    
    Thanks in advance,
    
    		- Valerie

I did not read all the preceeding notes in detail, but color operation has not
changed in V2.  Neither is there a drag extension.

Do a DIR/AUTHOR=PROJECTS/SINCE=1-DEC-1989 and I think you will find a note
about this sort of thing with lots of discussion.

Burns

    
    RE: .7
    
    Thanks for the pointer (the discussions are in notes 1902, 1905, and
    1985, by the way).
    
    However, those discussions are from a DECwindows programmer's
    perspective.  I was looking for something from a DECwindows user's
    perspective.
    
    I.e. some resource I could put into my DECW$XDEFAULTS.DAT file to set
    the color, or some information like "the color is the same as
    BorderColor" or "the color is the same as the screen background color",
    or some hints like how to order the color settings of various resources
    in DECW$XDEFAULTS.DAT to affect the color, etc...
    
    Does anyone have any information like that?
    
    
    Thanks in advance,
    
    		- Valerie