[GRASS5] Re: more on color rules

[Michael Barton]

Well, since my question/bug report set off this discussion of ways to 
improve raster color management, I hope I can put my oar in. I agree 
with Hamish about the number of color rules files not really being a 
problem. On the other hand, there is no point in making the 
interface/options more complicated than necessary. Here is an idea. It 
seems that there are 3 things a user might want to do

1. use a set of predefined color rules, including those that come with 
GRASS by default (these could be 'unmodifiable') and any others he/she 
might acquire
2. interactively create a set of color rules 'on the fly' via the xterm 
standard entry (or a nicer interface if possible)
3. use the color rules from another map. This is really just an 
alternate version of #1, but is added as a convenience to make it 
easier to match color tables from one map to another.

Given this, it seems that there needs to be 2 options for reading in 
files: rules=[predefined rules, including the default GRASS set] and 
map=[for reading rules from another map]; and one flag for interactive 
rule creation on the fly. The flag would override the options (more 
convenient than having to make sure the options are blank in the GUI). 
I definitely like the idea of having the rules option somehow 
autogenerate a list in the GUI. For the CLI, the displayed options 
could be limited to the default GRASS set to keep it from getting too 
cluttered.

Michael Barton
____________________
C. Michael Barton, Professor
School of Human Origins, Cultures, & Societies
PO Box 872402
Arizona State University
Tempe, AZ  85287-2402
USA

Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>
On May 11, 2004, at 2:01 AM, grass5-request at grass.itc.it wrote:

>
>>>>> Also, it won't even get this far from the autogenerated GUI
>>>>> because it conflicts with the type=[option] argument. There
>>>>> needs to be a 'none' selection for the type option in the GUI
>>>>> header.
>>>>
>>>> It needs to be a separate menu entry; exactly the same issue also
>>>> applies to the rast= option.
>>>
>>> What about a function which reports the names of the currently
>>> existing files in $GISBASE/etc/colors/ ? A function which
>>> returns the file names as comma separated list?
>>
>> The problem here is that the list could grow rather quickly now that
>> it can be extended without having to write any code.
>
>
> I don't see this as a big problem if the default install is limited to
> a dozen or so default color scales (we shouldn't be drowning the users
> with many like options IMO).
>
> If someone wants to install 200 custom rules files, they get to deal
> with the consequences... same as if they installed 200 TT fonts on 
> their
> computer.
>
>
> Perhaps we should add a -l flag to list available rules? Then the
> default help page/parser stays clean.
>
>
> see 'g.mapsets -l'
>
>
> Hamish
>
>