Hi Chuck,
> Um... it IS drawn with XOR. You may have to play with XORValue. From
> the man page:
>
> XORvalue number
> Changes the value with which bits are XOR'ed when doing
> rubber-band window moving or resizing. Setting this
> value is a trial-and-error process.
>
> Try 1 (which I use with a black background), then 255 (the default
> actually), as I think these are the best bets (unless you have a
> TrueColor/DirectColor visual _at_ 24 bpp, in which case try 250, which
> worked for someone I know).
Thanx! I chose 1 and it worked fine.
What is the actual problem with the XORValue? Why is it trial-and-error
process? Is it because you cannot acutally choose a color value, but
have to choose a color with a number?
If I have a color value of e.g. black: 00 00 00. If I xor this
with FF FF FF, I get FF FF FF. Thus I would always get the 'reverse'
color.
But on non true color systems I probably have colormap entry
black is e.g. 2, and 2 xor 255 yields 253, which might also contain
a very dark color, maybe the same as black. Is that the problem?
Guenther
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Thu Oct 03 1996 - 10:52:52 BST