[GRASS-dev] lib fn to convert int color number to RGB values?

[Glynn Clements]

Hamish wrote:

> > If I pass the colors as a single RGBA_Color struct, I would like to
> > have a parsing lib fn to replace D_parse_color(). It would call
> > G_str_to_color() then fill the RGBA_Color struct, like
> > set_last_color()
> > in d.graph. e.g.:
> >   G_str_to_RGBA(char* str, RGBA_Color color);
> 
> already done as set_RGBA_from_str() in
>   display/d.paint.labels/color.c
> 
> 
> > but for GRASS 7 does that belong in libgis?
> 
> I suggest putting the RGBA helper functions found in d.paint.labels/
> color.c into libgis (color_rgba.c), except for set_color_from_RGBA()
> which is a frontend to R_RGB_color() and belongs in libraster(?).

Anything which calls R_RGB_color() belongs in either libraster or
possibly libdisplay. libgis doesn't require either of those, so it
can't go into libgis.

> Perhaps those fns could have more grass-consistent G_() names and
> variable order, but I'm unsure of classic C conventions for those.
> Normally I wouldn't care, but if these will be used commonly in GRASS 7
> I'd like to spend the little extra discussion time now to get
> everything clean and in its most-useful state, rather than just impose
> my whim of the day and be cursed for it later.
> 
> As lib fns, the one G_fatal_error() would need to change to
> G_warning().
> Or is it better to be silent and rely on the module programmer to check
> the fn's return code?

If it's conceivable that the module will continue in the event of an
error, the function should just return a status code.

If it's likely that the module is just going to call G_fatal_error()
anyhow, the library function may as well call it itself, thereby
providing a "infallible" interface (i.e. the function never fails; it
either succeeds, or the process is no longer running so the failure is
moot).

The advantage of the latter is that individual modules don't have to
concern themselves with error handling, and you are guaranteed to have
consistent error messages (rather than a slightly different messsage
for each module which uses the function).

The former is only an advantage if there's a situation where a module
doesn't just call G_fatal_error() when an invalid colour occurs. Given
that invalid user input is usually a fatal error, I can't immediately
think of a situation where you might get an invalid colour string
without it resulting in a fatal error.

BTW, another "bulk" change for 7.x: eliminate bogus "int" return
types. Many of these stem from pre-ANSI C, which didn't have "void". 
Functions which always return zero should be changed to have "void"
return type.

-- 
Glynn Clements <glynn at gclements.plus.com>