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.
Michael
On 1/31/07 4:12 AM, "grass-dev-request@grass.itc.it"
<grass-dev-request@grass.itc.it> wrote:
Send grass-dev mailing list submissions to
grass-dev@grass.itc.it
To subscribe or unsubscribe via the World Wide Web, visit http://grass.itc.it/mailman/listinfo/grass-dev
or, via email, send a message with subject or body 'help' to
grass-dev-request@grass.itc.it
You can reach the person managing the list at
grass-dev-owner@grass.itc.it
When replying, please edit your Subject line so it is more specific
than "Re: Contents of grass-dev digest..."
Today's Topics:
1. Re: Re: gui startup bug (new locn by epsg code) (Michael Barton)
2. Fwd: grass compilation problem (Reddog Blackcat)
3. Re: [GRASS-user] v.buffer creates artefact - bug? (Moritz Lennert)
4. Re: Re: gui startup bug (new locn by epsg code) (Paul Kelly)
5. Re: Re: gui startup bug (new locn by epsg code) (Paul Kelly)
6. Re: r.colors: rules file list unsorted (Paul Kelly)
_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it http://grass.itc.it/mailman/listinfo/grass-dev
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
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.
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:
> 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.
This is exactly how I was envisioning it. This makes it relatively easy to
occasionally add to or change the default color tables that ship with GRASS,
and also makes it easier for a user to access their own custom color tables.
Michael
On 1/31/07 8:10 PM, "Glynn Clements" <glynn@gclements.plus.com> wrote:
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.
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
