[GRASS5] Color code cleanup

[Hamish]

> >  gis.h doesn't have a RGBCOLOR struct in it.
> > (e.g. SYMBCOLOR in symbol.h)
> >
> > I'd have such a creature as so:
> >
> > (in gis.h)
> >
> > typedef struct {
> >     int set;  /* 0 unset, 1 set, -1 "none" */
> >     unsigned char r, g, b;
> > } RGBCOLOR;
> >
> 
> Why do we need to keep track of set information?

It's good accounting practice.
We need a meta-place holder for "none" anyway.


> Since structs are sometimes but not consistently initialized to zeros
> by compilers this seems like an easy way to make bugs that are very
> difficult to track down.

I think that bug would be pretty easy to track down. If the compiler
initialized it to 0 (CFLAGS="-g"?), the default is "unset", which tells
you pretty quick that you forgot something when you go to use it.
If everything comes up as 0:0:0 black you've got a good lead too.

> This is everything I can think of that could go in a color:
> 
> typedef struct {
>     int standard;  /* Positive integer if this is a standard color, 0 
> otherwise*/
>     unsigned char r, g, b, a; /* red, green, blue, and alpha */
>     float fr, fg, fb, fa; /* This is twice as big as everything else
>     combined 
> */
> } RGBA_COLOR;

I do like adding the alpha channel for GUI future-proofness.
I have no idea if it will ever be useful*, but it only costs a byte.
  *(guidance from the GUI experienced please?)
For now it does mean setting it to 1 every time you set a color, which
is extra work for little gain.

What's the point of knowing if there's an equivalent standard color?
If dealing with standard colors, wouldn't you just use
D_raster_use_color() or R_standard_color() in the first place and not
bother with RGB? Are the standard colors that much faster to use that
knowing you had one would make a difference in the 1 in 10^6 chance
that you hit one?


> None can simply be alpha==0. An easy way to check this is just:
> 
> if (color.a) {
> 	do something
> }

mmmhh. It would work, but I'm not crazy about mixing concepts.
In a practical sense I see how 99.9% of the time they are the same
thing, and I'm having a hard time trying to think of a case where
"color=none" doesn't mean "transparent", but I do consider "none" more 
of an absence case than a alpha=0 case.

Logically, "if(color.set != TRUE) continue;" is a lot better and
readable than "if(!color.a) continue;".

If used uninitialized (& compiler sets to 0) it could be frustrating to
figure out why objects randomly don't display. If used uninitialized
and the compiler hasn't initialized it anything, you've got a very good
chance of bizarre random shading.

..... I'm still preferring to have the set flag in there.


> I think the floats should probably go. We might want some shared
> structure for them, but it'd be separate anyway.

I agree. Who knows how far off analog displays are? (retro!)
So far I haven't heard a case for when fp color would be used. Anyone?
(besides PostScript...)


If there are no objections, I'll add this to gis.h in the coming days:

typedef struct {
    int set;  /* 0 unset, 1 set, -1 "none" */
    unsigned char r, g, b, a;  /* red, green, blue, and alpha */
} RGBA_COLOR;


I would like to get this right the first time.


Hamish