Hi,
Color change for d.grid -c,-f is now working.
http://trac.osgeo.org/grass/changeset/29944
Please review.
Hamish
Looking for last minute shopping deals?
Find them fast with Yahoo! Search.
Ivan Shmakov wrote:
RGBA_Color was recently added (as was RGB support for modules' CLI
options) so 1) it could be used to pass RGB arround without having to
call the display library and 2) we could handle a color value of
'none' without needing to pass a separate variable or rely on
Ivan Shmakov wrote:
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
Glynn Clements [EMAIL PROTECTED] writes:
[...]
The GRASS libraries are fundamentally designed to be used in
one-shot modules. Errors are handled by printing a message then
exiting. Variables are either initialised at startup from the .data
and .bss segments or are initialised upon first
Hamish [EMAIL PROTECTED] writes:
[...]
s/RGB_Color/RGBA_Color/ ?
no, the idea there was to be a shortcut for those who wanted to use
the struct but didn't care about alpha and didn't want to cause
confusion in the variable namespace. In those cases the alpha channel
is ignored and
Ivan Shmakov wrote:
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
Ivan Shmakov wrote:
if (color = 0) return 0;
BTW, is it a GRASS convention to use 0 to indicate failure?
Standard C library functions tend to use -1 for failure, while using
non-negative values to indicate success.
The SUBMITTING file in the source code says:
8. Exit
Ivan Shmakov wrote:
AFAIK, GRASS itself never sets errno.
But, IIUC, it doesn't prevent `errno' from being set by the
standard library functions it calls?
Setting `errno' would make sense should there be a demand to use
the standard C means of error reporting
Hamish wrote:
Is a new D_number_to_RGB(int color, unsigned char r,g,b) fn
needed in lib/display/tran_colr.c?
Glynn:
Yes. E.g.:
int D_color_number_to_RGB(int color, int *r, int *g, int *b)
{
const struct color_rgb *c;
if (color = 0)
return 0;
if
Glynn Clements [EMAIL PROTECTED] writes:
[...]
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
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);
Moritz Lennert [EMAIL PROTECTED] writes:
[...]
int D_color_number_to_RGB(int color, int r, int g, int b)
[...]
if (color = 0) return 0;
BTW, is it a GRASS convention to use 0 to indicate failure?
Standard C library functions tend to use -1 for failure, while using
non-negative
Hamish wrote:
All of this should really be harmonised;
Yes please.
I'm just wondering whether it's too late to do it for 6.4.
For 6.x I would suggest it is wasted effort to do so, and against the
goal of pre-release stabilization.
2 cents
My hope is that we release 6.3.0 soon
Ivan Shmakov wrote:
Is a new D_number_to_RGB(int color, unsigned char r,g,b) fn
needed in lib/display/tran_colr.c?
Yes. E.g.:
int D_color_number_to_RGB(int color, int r, int g, int b)
{
That looks a lot like C++. Surely it will work with C89?
Oops. I meant:
Glynn Clements [EMAIL PROTECTED] writes:
[...]
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
Glynn Clements [EMAIL PROTECTED] writes:
[...]
if (color = 0) return 0;
BTW, is it a GRASS convention to use 0 to indicate failure?
Standard C library functions tend to use -1 for failure, while using
non-negative values to indicate success.
The GRASS convention is to use a
Hamish wrote:
Is a new D_number_to_RGB(int color, unsigned char r,g,b) fn
needed in lib/display/tran_colr.c?
Glynn:
Yes. E.g.:
int D_color_number_to_RGB(int color, int *r, int *g, int *b)
{
const struct color_rgb *c;
if (color = 0)
return 0;
if (color =
Hamish wrote:
I am looking for a library function to get the R,G,B values (0-255)
for an integer color number which was created with D_parse_color().
Glynn:
That information isn't available at present.
Also, the concept of colour numbers is likely to go away entirely in
7.x. With the
Hamish wrote:
Is a new D_number_to_RGB(int color, unsigned char r,g,b) fn
needed in lib/display/tran_colr.c?
G:
Yes. E.g.:
int D_color_number_to_RGB(int color, int r, int g, int b)
{
const struct color_rgb *c;
if (color = 0)
return 0;
if (color =
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
Glynn Clements [EMAIL PROTECTED] writes:
[...]
Is a new D_number_to_RGB(int color, unsigned char r,g,b) fn
needed in lib/display/tran_colr.c?
Yes. E.g.:
int D_color_number_to_RGB(int color, int r, int g, int b)
{
That looks a lot like C++. Surely it will work with C89?
Hamish wrote:
Is a new D_number_to_RGB(int color, unsigned char r,g,b) fn
needed in lib/display/tran_colr.c?
Glynn:
Yes. E.g.:
[...]
Hamish:
Any reason you use int for the r,g,b type? color.h defines
{}color_rgb as unsigned char, as does gis.h's {}RGBA_Color. I'd
like to avoid
Hi,
I am looking for a library function to get the R,G,B values (0-255) for
an integer color number which was created with D_parse_color(). I don't
want to set the color for drawing, just get the RGB component values so
I can populate a RGBA_Color struct. Reparsing the original color string
isn't
On Jan 28, 2008, at 8:32 AM, [EMAIL PROTECTED] wrote:
Date: Mon, 28 Jan 2008 04:30:21 -0800 (PST)
From: Hamish [EMAIL PROTECTED]
Subject: [GRASS-dev] lib fn to convert int color number to RGB values?
To: grass-dev@lists.osgeo.org
Message-ID: [EMAIL PROTECTED]
Content-Type: text/plain
24 matches
Mail list logo
