[GRASS5] Which colors are right?

So, I was looking at fixing that d.area dig_list problem, when I found
the current sources don't compile. Amongst the rubble was the redefinition
of all the defined colors in colors.h and vect/dig_defines.h -- and the
definitions don't match! How this could be the case for so long and
not cause an error, I don't know. But, the GRASS standard color defines
should only live in one place. I'm voting to drop the definitions in
dig_defines and have it include colors.h. But, I don't yet know the
ramifications of doing so...

--
Eric G. Miller <egm2@jps.net>

On Tue, 20 Nov 2001 19:44:50 -0800
"Eric G. Miller" <egm2@jps.net> wrote:

So, I was looking at fixing that d.area dig_list problem, when I found
the current sources don't compile. Amongst the rubble was the redefinition
of all the defined colors in colors.h and vect/dig_defines.h -- and the
definitions don't match! How this could be the case for so long and
not cause an error, I don't know. But, the GRASS standard color defines
should only live in one place. I'm voting to drop the definitions in
dig_defines and have it include colors.h. But, I don't yet know the
ramifications of doing so...

As follow-up, I made a few modifications to colors.h and vect/dig_defines.h
and so far it looks okay. I'm updating my CVS and will do a rebuild followed
by some other checks. At least v.digit seemed to get color numbers by
string name, so it seems okay...

--
Eric G. Miller <egm2@jps.net>

On Tue, Nov 20, 2001 at 08:36:49PM -0800, Eric G. Miller wrote:

On Tue, 20 Nov 2001 19:44:50 -0800
"Eric G. Miller" <egm2@jps.net> wrote:

> So, I was looking at fixing that d.area dig_list problem, when I found
> the current sources don't compile. Amongst the rubble was the redefinition
> of all the defined colors in colors.h and vect/dig_defines.h -- and the
> definitions don't match! How this could be the case for so long and
> not cause an error, I don't know. But, the GRASS standard color defines
> should only live in one place. I'm voting to drop the definitions in
> dig_defines and have it include colors.h. But, I don't yet know the
> ramifications of doing so...

As follow-up, I made a few modifications to colors.h and vect/dig_defines.h
and so far it looks okay. I'm updating my CVS and will do a rebuild followed
by some other checks. At least v.digit seemed to get color numbers by
string name, so it seems okay...

Hi Eric, hi all

I also realized that several color definitions are spreaded in GRASS.
Can we reduce it to one only? When v.digit and others work string based
rather than color index based, it should not break anything.

So I propose to keep only src/includes/colors.h

Markus

On Tue, Nov 20, 2001 at 08:36:49PM -0800, Eric G. Miller wrote:

On Tue, 20 Nov 2001 19:44:50 -0800
"Eric G. Miller" <egm2@jps.net> wrote:

> So, I was looking at fixing that d.area dig_list problem, when I found
> the current sources don't compile. Amongst the rubble was the redefinition
> of all the defined colors in colors.h and vect/dig_defines.h -- and the
> definitions don't match! How this could be the case for so long and
> not cause an error, I don't know. But, the GRASS standard color defines
> should only live in one place. I'm voting to drop the definitions in
> dig_defines and have it include colors.h. But, I don't yet know the
> ramifications of doing so...

As follow-up, I made a few modifications to colors.h and vect/dig_defines.h
and so far it looks okay. I'm updating my CVS and will do a rebuild followed
by some other checks. At least v.digit seemed to get color numbers by
string name, so it seems okay...

Hi,

I have searched the source code for more local color definitions:

#define MY_COLOR_LIST
"red,orange,yellow,green,blue,indigo,white,black,brown,magenta,aqua,gray,grey,fromcell"
293716 12 -rw-r--r-- 1 neteler ssi 10177 Nov 13 14:17
./src/display/d.rast.num/number.c

  opt2->options =
"white,red,orange,yellow,green,blue,indigo,violet,magenta,brown,gray,black";
33676 4 -rw-rw-r-- 1 neteler ssi 2737 Aug 24 15:28
./src/display/d.vect.cats/main.c

#define D_COLOR_LIST
"red,orange,yellow,green,blue,indigo,white,black,brown,magenta,aqua,gray,grey"
131084 12 -rw-r--r-- 1 neteler ssi 9856 Oct 19 14:55
./src/display/d.vect.labels/main.c

      fprintf(stderr," orange grey magenta aqua indigo violet brown\n\n");
32785 4 -rw-rw-r-- 1 neteler ssi 3147 Jul 7 2000
./src/mapdev/v.area/where_am_i.c

"orange", "gray", "brown", "magenta", "white", "indigo", "NULL"};
    y_color_opt->options =
"white,red,orange,yellow,green,blue,indigo,magenta,violet,brown,gray,black";
    t_color_opt->options =
"white,red,orange,yellow,green,blue,indigo,magenta,violet,brown,gray,black";
358518 20 -rw-rw-r-- 1 neteler ssi 18362 Jun 18 11:20
./src.contrib/PURDUE/d.linegraph/cmd/linegraph.c

    plot->description =
"Colors:red,orange,yellow,green,blue,indigo,violet,magenta,brown,gray,white,black;Icon:diamond,
box, plus, x; Size: 1-9. ";
244596 8 -rw-rw-r-- 1 neteler ssi 4749 Aug 6 16:08
./src.garden/grass.postgresql/d.site.pg/main.c

At least these are suspicious. For parameters the function
D_color_list();
should be fine instead of harcoding the colors.

Due to the conference I cannot change that, anyone else volunteering?

Thanks in advance,

Markus

Markus Neteler wrote:

I have searched the source code for more local color definitions:

At least these are suspicious. For parameters the function
D_color_list();
should be fine instead of harcoding the colors.

Due to the conference I cannot change that, anyone else volunteering?

I'll do it.

--
Glynn Clements <glynn.clements@virgin.net>

On Thu, Nov 22, 2001 at 08:04:39PM +0000, Glynn Clements wrote:

Markus Neteler wrote:

> I have searched the source code for more local color definitions:

> At least these are suspicious. For parameters the function
> D_color_list();
> should be fine instead of harcoding the colors.
>
> Due to the conference I cannot change that, anyone else volunteering?

I'll do it.

Glynn,

thanks a lot for all the color fixes and the atof() mess fixes.

I always try to catch compiler warnings were I find them, but
for missing includes we may use a smart script (if XXX is present,
check for YYY.h)? Perhaps too brute-force.

Markus

Markus Neteler wrote:

thanks a lot for all the color fixes and the atof() mess fixes.

I always try to catch compiler warnings were I find them, but
for missing includes we may use a smart script (if XXX is present,
check for YYY.h)? Perhaps too brute-force.

Or just too much work. Between them, glibc's stdlib.h, stdio.h and
string.h have about 300 external function declarations, and unistd.h
and fcntl.h have a further 150.

--
Glynn Clements <glynn.clements@virgin.net>