[GRASS5] Color prompt partially implemented, color confusion.
cedricgrass at shockfamily.net
Sun Apr 16 18:33:48 EDT 2006
Other grass developers,
I have partially implemented a color prompt. It works for the colors
recognized by G_str_to_color. The gisprompt for it is "color,grass,color".
(It also works for tcltk colors of the #RRGGBB variety with the prompt
"color,tcltk,color"). In command line interactive mode the prompt is ignored
and entry works as before.
There is much disparity in the code relating to colors in the display modules,
enough to generate compiler warnings. Display module option colors come in at
least three flavors:
* red green and blue specified via G_str_to_color
These programs use G_str_to_color to parse colors. They then either look for
the color in the color table or possibly add it. I added gisprompts of the
form "color,grass,color" for all of these.
These generate the warnings:
warning: passing argument 1 of ‘R_RGB_color’ with different width due to
prototype (d.graph, d.vect, d.vect.chart)
warning: passing argument 1 of ‘R_reset_color’ with different width due to
prototype (d.mapgraph, d.path, d.vect)
* An already allocated, named color via D_translate_color.
These are probably best served by the options list.
* either red:green:blue or the name of an already allocated, named color.
There programs usually allocate a color for each option, implement their own
parsers for red:green:blue colors and define that color to be the result of
parsing, or if a named color is used replace the reference to their allocated
color with the number of the named color (gotten via D_translate_color).
These might be well served by another color prompt, say "color,display,color".
They might also be better off looking for an existing matching color and
using it if it exists, otherwise adding a new color, and if that fails
picking the closest existing color. This could (and might already be) all
bound up in a single procedure that takes a string for a color and returns an
index into the color table to the most appropriate color.
These also tend to use R_reset_color and generate warnings.
The main issue boils down to the following: Is it better to have consistent
color names between D_translate_color and G_str_to_color, or to have the
color names currently used have the same meanings they did in the past. If
consistency is more important then the color tables should be made to match
and a single prompt should be used for both. If backwards compatibility is
more important then we should have multiple prompts.
Differences in named color definitions:
G_str_to_color ignores case.
D_translate_color is case sensitive
name D_translate_color G_str_to_color
red 255 0 0 same
orange 255 128 0 255 127 0
yellow 255 255 0 same
green 0 255 0 same
blue 0 0 255 same
indigo 0 128 255 0 127 255
violet 255 0 255 same (this is a strange violet)
black 0 0 0 same
white 255 255 255 same
gray 175 175 175 127 127 127
brown 180 77 25 same
magenta 255 0 128 255 0 255 (D_ has a very strange magenta)
aqua 100 128 255 100 127 255
grey lookup to gray 127 127 127
cyan doesn't exist 0 255 255
How should we straighten out these colors?
More information about the grass-dev