[GRASS5] Suggested color function names

[Hamish]

> > 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);
> 
> In the case where "none" means "completely transparent" (i.e. not
> drawn), I would suggest using the alpha component.

Ok, that is its main (only?) use in the current display modules.

A last (mostly Devil's Advocate) argument for color.set=NONE; instead of
color.alpha=0;  -- what if in the future someone gets the bright idea to
add a overall display alpha slider into a future GUI, and implemented as
a+=30;. That would break the 0=none assumption and probably start using
un-inited variables. (the lazy might set c.a=0; and skip .r = .g = .b
=?;)

 
> To me, a "set" field implies "the data in this structure is/isn't
> valid" (i.e. "undefined"). If a function fills in caller-provided
> structures, the field being zero means "I haven't filled this in",
> while an input having the field set zero means "ignore this value"
> (e.g. leave the previous setting unchanged).

yes, that is my thinking too. Current choices are set|unset|set to none.
There is some functional overlap between "unset" and "set to none" but
they are logically different things.

> If you're concerned about code clarity, using "if (color.a > 0)" may
> be clearer.

Yes, that's better.

> Or even making the display (D_*) functions perform this optimisation
> internally (the application always calls the "draw" function, but the
> library would skip drawing if the current colour is transparent).

It should probably be done in the module for clarity of purpose and in
the library for redundancy & efficiency.


> Alternatively, provide R/G/B/A and R/G/B/Set types, both 32 bits.

no opinion, other than it seems redundant to do so. I am happy with
picking one style which the best for the future development but which
also I can use with today's display modules without massive rewrites of
their logic.


> > > 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.
> 
> Well, the more it's used, the more it makes sense for it to fit into a
> 32-bit word.

And the more it fits into 32 bits the more it will be used, etc etc etc

> Lots of graphic APIs have RGB/RGBA colour structures, and most of them
> don't have a "set" field.

GRASS used this method in the past, which is where I derived my
inspiration for using it.


To be clear, I am happy with whatever is the best technical solution .. 


Hamish