Conference bulova::decw_jan-89_to_nov-90

Re: .0

In DECterm's case, using XOR to blink on colored backgrounds *is* the right
thing to do, because that's how it works on real terminals.  I'm not sure
about Stext; it might be able to get away with XOR as long as it sets the
plane mask to the XOR of the foreground and background colors (this is
assuming that the Stext window is opaque).

				-- Bob

So should there be a qar against stext since it doesn't always display 
the foreground for the cursor as documented?

Sure, try it.  However, you might also try thinking of a suggestion for how
to do blinking efficiently without using XOR, which works on PseudoColor,
TrueColor and StaticGray, and which does not use up half the colors in the
colormap, in the PseudoColor case. 

The window manager could use that information too...

(This is not really intended to be tooooo sarcastic.  We would really love to
have some ideas.  The best we have thought of is to do a GetImage on the
bits under the cursor and then restore them after the cursor moves, but this
seems dreadfully slow...)

Burns

Sarcasm accepted because I feel the same way.

It seems to me that the previous suggestion of using the xor of the 
foreground and background to create the plane mask will solve the 
problem and keep the efficiency of the xor draw request even if it 
takes a little more to keep track of the magic plane mask for each 
widget.

Initially I put the customer off saying "that's the way it works for 
efficiency", but they have valid reasons for making different color 
stexts and the more I think about it the more I think it is a 
deficiency, especially when it ends up invisibly blinking in the
background color! 

I think we owe the user a predictable cursor even if it can't be as
efficient because of a background color.  Do it the best way possible
and document it as slow.  I don't think the current workaround of
taking control of the complementary colors in the map is acceptable
long term. 

If the plane mask approach doesn't work you could always just draw the 
components of the stext cursor in the foreground/background colors 
without doing the getimage.  It looks like the cursor always is over 
background and can be contained in three rectangles that won't overlap 
text.  Doing it right and taking an efficiency hit is preferable to 
unpredictability.  After all, these machines are only human! :)

Bruce

	Has anyone considered a server extension to do cursor blinking?
	It'd solve the network badnwidth/client resources problems, and
	it may be easier for the server than the client to deal with the
	color problem...

	Mike

    re .4:  Aha...my aging brain dropped some of the earlier discussion. 
    Yes, the plane mask business works for XOR if there are only two
    colors on the screen.  Or more generally, iff any color you can make
    by starting with any defined color that the cursor might be over and
    scrambling the bits in the plane mask you are guaranteed to have a
    contrasting color.  The former more restrictive condition is the most
    common and easily-guaranteed case of the more general condition.  This
    may work with the text widget, but not for the window manager (which
    sometimes has to deal with crossing <<gag>> windows of multiple visual
    types!
    
    re .5:  An excellent idea.  Of course, any application that used it
    would have to fall back to the old scheme if it could not find it.
    If anyone would like to generate straw-person specs for such a thing, it
    would be interesting to speculate about.  In the meantime, while this
    situation really annoys me, we have had surprisingly w complaints about
    it!
    
    Burns
    
    Burns
    

I see two cases:
1) Blinking with only foreground and background with an easy xor 
solution.

2) Blinking over complex or pixmap backgrounds needing an extension to 
solve properly.

While I encourage the general solution it will take a long time.  What 
are the chances of doing the xor for the plane mask sooner since it 
would cover the most common situations with stext and decterm?  
Besides, there's less of a problem using the current method on complex
backgrounds because there's a high probability of at least being visible 
with more pixel values.

>In the meantime, while this situation really annoys me, we have
>had surprisingly w complaints about it!

So have we, but a lot of users are just starting to use colors.  If it 
annoys you it will them, too.
    
Bruce

    I can't speak for the toolkit or terminal folks.  Maybe a QAR *is* the
    right avenue if you limit it and give the solution.
    
    Burns

    A solution I've used in the past is to make the cursor not interfere with
    the text. That way you do blink with paint and erase. Doesn't SText have
    this option? If you "mostly" don't interfere, like with an underbar or
    an "I-Beam" you can use the xor/planemask trick. Since most of what you
    will be xor'ing with is background, most of your cursor will be contrasting.

    Re: Server extension for blinking

    I really wanted such a thing early in the toolkit days. Some sort of notion
    of timer/time-out in the server would have made double-click MUCH nicer.
    As it is, "non-destructive" double click (double-click that doesn't do the
    single-click action) can only be done probabalistically.

    Re: server extension for contrasting colors.

    Define a drawing mode "contrasting". Every place you would draw the GC
    foreground color, you instead look at the existing pixel, and pick a color
    to draw based on the existing pixel color. We could do this by defining
    a colormap for "contrasting" colors on PseudoColor, or a function to use
    on TrueColor. On StaticGray depth 1 (monochrome) displays this would default
    to the same behavior as xor.

    We would need an "undo" function as well, that might be a bit trickier but
    I think we can solve it using conventions?

	-- Charles

    As a  minimialist  version of a blinking proposal, would it be possible
    to pass two  sequences  of protocol requests across the wire, one which
    painted the "blinked" object in normal rendition, the other of painting
    the object  in the reversed rendition?  By specifying an "on" and "off"
    interval with the  request,  the  server  extension  could  keep a time
    sorted work queue which  simply passed the apprporiate list of requests 
    through to the server.

    This  approach  has  the attraction  of  allowing  arbitrarily  complex
    objects to blink.  The application  would  have  the  responsibility of
    knowing  when  the shape of the object,  its  intersection  with  other
    objects in the window, or its color changed.   When one of these events
    occured,  the  application  would  unregister  the  first  request  and
    register a new blink request with the new attributes.
    
    It occurs to me that this design for blink also  lends itself well to a
    sort  of  "macro" facility, wherein the application can send a sequence
    of  requests  to the server (which it knows it will do frequently)  and
    then later request that a given "macro" be replayed.
    
    Comments?
    
    James
    

Re: .-1 "Macros"

This is a kind of "display list" proposal. There have been various discussions
about adding some sort of display lists to X.

	-- Charles

Could a blinking cursor be done by using the PostScript extension?

There is a way in PS to get a time-tick, so in theory it should be doable,
however my local DPS wizards all winced when I suggested it, so...

	-- Charles

I don't think you would buy anything.  You still have to copy out whatever is
underneath and replace it.

Burns