[GRASS5] Color prompt partially implemented, color confusion.

[Cedric Shock]

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.
d.graph
d.mapgraph
d.path
d.vect
d.vect.chart

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?

--Cedric