[GRASS5] Suggested color function names

[Hamish]

> In what context does a colour of "none" make sense?
> 
> If you have a particular situation where you need additional
> information other than just a colour, then create your own type for
> that purpose.


Many of the display modules use a color of "none" to switch off the
drawing of some feature.

e.g. d.barscale background color.
e.g. d.vect fill or outline color. (vector area or symbol)
e.g. d.rast.arrow grid color.

Typically in a d.* module the color is taken from the command line:
    color  either a standard GRASS color, R:G:B triplet, or "none"
           default: white

which is then parsed and the result passed on to an external draw fn:
   do_plot(,,,, color);


If this was only used sparsely I can see the point of keeping RGBA_Color
compact and simple, but in practical use we'd use it all the time, and
you'd either have to define a new struct 50% of the time; change a large
number of function calls to add a really_draw_it flag; or start adding
the really_draw_it flag as a global variable. A "none" flag (aka draw
nothing/be transparent) in the color struct makes defining this
situation much more elegant- nan:nan:nan. Also it's a lot clearer to the
casual code reader seeing color.set=RGBA_COLOR_NONE; versus color.a=0;,
and I don't like conceptually mixing boolean tests with full fledged
int/char variables. [ if(color.a) draw_it(); ]


> There's no reason why everything which deals with colours needs to
> carry that field around because something which uses colours needs it.

What future plans do you have for widespead use of the RGBA_Color struct
which would make the above a corner case?

I can see the point about making it fit into 32 bytes etc if it is
destined for core use in the heart of the graphics engine*, but for the
current use I think the extra bloat justifies itself well.

[*] in that case make RGB_Color {r,g,b} and keep RGBA_Color as is, or
something along those lines.


Hamish