I found an undocumented environment variable "XDRIVER_TRUECOLOR" in
display/drivers/XDRIVER/XDRIVER24/Graph_Set.c. Shouldn't this be renamed
to GRASS_TRUECOLOR?
I'm just curious about:
1. why XDRIVER doesn't support GRASS_BACKGROUNDCOLOR
2. why d.erase wipes out the monitor with DEFAULT_BG_COLOR by default,
not by GRASS_BACKGROUNDCOLOR
3. why we don't have GRASS_FOREGROUNDCOLOR
Thanks.
Huidae Cho
Huidae Cho wrote:
I found an undocumented environment variable "XDRIVER_TRUECOLOR" in
display/drivers/XDRIVER/XDRIVER24/Graph_Set.c. Shouldn't this be renamed
to GRASS_TRUECOLOR?
The two don't do quite the same thing.
XDRIVER_TRUECOLOR causes the driver to prefer a TrueColor visual over
the default visual. Whether the display is paletted or true-colour
depends upon the visual which is actually selected, which may or may
not match the setting of the environment variable.
GRASS_TRUECOLOR forces the creation of true-colour PNG images. It was
added so that true-colour support could be added without breaking
backward compatibility with previous versions of the PNG driver which
always created paletted images.
I'm just curious about:
1. why XDRIVER doesn't support GRASS_BACKGROUNDCOLOR
No particular reason; it just wasn't implemented.
2. why d.erase wipes out the monitor with DEFAULT_BG_COLOR by default,
not by GRASS_BACKGROUNDCOLOR
d.erase cannot determine the setting of that variable in the monitor.
It could use the setting from its own environment, but there's no
guarantee that the active monitor uses the same setting.
3. why we don't have GRASS_FOREGROUNDCOLOR
It isn't really meaningful; the current colour is mutable state. At
most such a variable could set the inital value of the current colour,
but many programs will explicitly set it to something else. There is
no operation to revert to a "default" drawing colour.
--
Glynn Clements <glynn@gclements.plus.com>