[GRASS5] r.colors again

[Glynn Clements]

Michael Barton wrote:

> I was messing around with r.colors for 5.7. As it is currently (or at 
> least as of 4/24 - my current installation) it is pretty close to what 
> I was suggesting. For what it is worth, the changes I'd recommend are:
> 
> 1. change the rules=[file] so that it just looks for a color table file 
> in any user-defined location, not $GISBASE/etc/colors. It should have a 
> gisprompt: 'file,file,file' in the tcltk header for g.parser to read. 

No. As I've said at least twice before, that is *not* the purpose of
the "rules=" option. The "rules=" option is intended solely as a
transitional measure.

The fact that the arguments to rules= happen to be files is an
implementation detail, which shouldn't be visible to the user.

The idea was that it would ultimately be merged with the "colors="
option. Instead of the argument to colors= referring to one of a
hardcoded list of coded colour tables, it would refer to an extensible
list of *predefined* rule files.

I had considered simply changing to the behaviour of the color=
option, but I decided against it because I didn't want to risk
breaking anything.

For the time being, you have a choice of two methods for using one of
(most of) the standard colour tables: color= or rules=. I.e. using
"r.colors ... color=rainbow" and "r.colors ... rules=rainbow" should
produce identical results, just by different mechanisms.

However, this doesn't work for the "grey.eq", "grey.log", "random" or
"rules" options, as they can't be described by a fixed rule file.

I have suggested dealing with the grey.eq and grey.log cases by adding
additional switches for histogram-equalised and logarithmic tables
(e.g. "r.colors -e ... rules=grey" would be equivalent to
"color=grey.eq").

The "color=random" case would have to be handled specially (or moved
to a seperate r.colors.random program).

The "color=rules" case has always been problematic with regard to the
tcltkgrass interface. It's only within the last month or so that this
was usable within (5.3) tcltkgrass. And it seems to demonstrate a
fundamental issue with the auto-generated GUI, i.e. the need to
hand-code special cases.

> 2. split out the color=rules from color=[type], and make it a flag. 
> Currently, color=rules works from the command line but not from the 
> autogenerated GUI. Unlike the other color=[type] options, it needs to 
> exec an xterm. Making it a flag rather than a possible color type might 
> make this easier to solve. The color=[type] option could then be 
> described as 'predefined GRASS color tables' and the flag as 'create 
> color table interactively'

Typing rules on stdin is less than ideal. It might be better to just
add a "file=" option (equivalent to color=rules plus stdin
redirection) and require that the user stores their rules in a file. 

One possibility would be to extend the GUI for arguments of type
"file" to allow for temporary files (e.g. as an alternative to
choosing an existing file, you could press a button to create a
temporary file and open it in a text editor).

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