[GRASS-dev] r.colors

[Glynn Clements]

Hamish wrote:

> > Since we're talking about color rules, I should mention that it is
> > confusing to users to have 2 lists of predefined color tables show up
> > in the r.colors GUI. I know what the difference is, but it is not
> > obvious to most users. Since these additional rules files have been
> > accompanying GRASS for a couple years now how about...
> > 
> > 1. we include these color rules in the list of predefined color
> > tables, and 2. change the second list to a browse function where a
> > user could easily input her/his own color rules file without having to
> > use a redirect from the command line.
> 
> note that the second list (rules=) doesn't allow grey.eq, grey.log.
> 
> can the file browser be told to start out in $GISBASE/etc/colors?
>  (I'm pretty sure I already know the answer for TclTk: "no")
> 
> rules= files are easier to add and maintain, the only thing colors= has
> going for it is the rules can be little programs, and long time
> backwards compatitbility.

FWIW, my original plan was to change the color= option to use the
files once it had been tested and we had figured out how to deal with
the special cases (grey.eq, grey.log). Somewhere along the line, I
forgot about it.

> I guess the other option is a new rulesfile= file browser option to load
> custom rules, but I think your point was to reduce complexity :)
> Perhaps that's better for a wrapper script that pipes the input file
> into r.colors.
> 
> FWIW r.colors will take rules interactively if you start it with:
> 
> GRASS> r.colors map_name color=rules

I suggest adding a file= option; this would imply color=rules and read
the rules from a named file rather than stdin. The only differences
between this and rules= are:

1. rules= requires that the rules file reside in $GISBASE/etc/colors,
and
2. rules= has a list of valid options, while file= would accept any
filename.

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