AFAIU GRASS_RENDER_IMMEDIATE is used in GRASS7 to set up the display
driver, e.g. `cairo` or `ps`. Values TRUE or FALSE are ignored. In
this case I would suggest to rename this variable to GRASS_DISPLAY or
something similar.
Similarly GRASS_PNGFILE is used in cairo to set up for e.g. pdf file
(GRASS_PNGFILE=map.pdf), `ps` drivers defines GRASS_PSFILE. I would
suggest to use only one - generic variable, something like
GRASS_MAPFILE, GRASS_OUTFILE or GRASS_FILENAME.
AFAIU GRASS_RENDER_IMMEDIATE is used in GRASS7 to set up the display
driver, e.g. `cairo` or `ps`. Values TRUE or FALSE are ignored. In
this case I would suggest to rename this variable to GRASS_DISPLAY or
something similar.
Note that 6.x also understands e.g. "GRASS_RENDER_IMMEDIATE=PS" (the
only "immediate" drivers available in 6.x are PNG and PS; others
require the use of a monitor).
IOW, the usage is the same in 6.x and 7.0, except that 7.0 doesn't
recognise "FALSE" (you'll just get the default driver; cairo if it's
available, PNG otherwise).
But if we don't need compatibility, the names can be whatever we want.
Similarly GRASS_PNGFILE is used in cairo to set up for e.g. pdf file
(GRASS_PNGFILE=map.pdf), `ps` drivers defines GRASS_PSFILE. I would
suggest to use only one - generic variable, something like
GRASS_MAPFILE, GRASS_OUTFILE or GRASS_FILENAME.
Any opinions?
I have no particular opinion on the exact names. However, before
changing anything, we might want to consider whether these should be
environment variables or GRASS variables.
Over the years, GRASS has "collected" environment variables like
people collect stamps or coins, and the collection has become rather
large.
Some of these environment variables might be better off as GRASS
variables; this would allow them to be controlled through modules,
rather than requiring the user to set them on the command line.
The downside is that scripts (and wxGUI) would need to create a
temporary $GISRC file rather than just using a modified environment.
AFAIU GRASS_RENDER_IMMEDIATE is used in GRASS7 to set up the display
driver, e.g. `cairo` or `ps`. Values TRUE or FALSE are ignored. In
this case I would suggest to rename this variable to GRASS_DISPLAY or
something similar.
Note that 6.x also understands e.g. "GRASS_RENDER_IMMEDIATE=PS" (the
only "immediate" drivers available in 6.x are PNG and PS; others
require the use of a monitor).
IOW, the usage is the same in 6.x and 7.0, except that 7.0 doesn't
recognise "FALSE" (you'll just get the default driver; cairo if it's
available, PNG otherwise).
AFAIU all display drivers in G7 are "immediate", monitors as
implemented in G6 has been removed in G7. Right?
Similarly GRASS_PNGFILE is used in cairo to set up for e.g. pdf file
(GRASS_PNGFILE=map.pdf), `ps` drivers defines GRASS_PSFILE. I would
suggest to use only one - generic variable, something like
GRASS_MAPFILE, GRASS_OUTFILE or GRASS_FILENAME.
Any opinions?
I have no particular opinion on the exact names. However, before
changing anything, we might want to consider whether these should be
environment variables or GRASS variables.
Over the years, GRASS has "collected" environment variables like
people collect stamps or coins, and the collection has become rather
large.
Some of these environment variables might be better off as GRASS
variables; this would allow them to be controlled through modules,
rather than requiring the user to set them on the command line.
That's right, some of them started as shell variables (GRASS_GUI) and
later became GRASS variables (e.g. GRASS_GUI) without changing the
variable name. Manual page variables.html became quite outdated by
time. I would incline to minimalize shell variables if possible. Could
we collect minimal group of shell variable which we need?
The downside is that scripts (and wxGUI) would need to create a
temporary $GISRC file rather than just using a modified environment.
Some of these environment variables might be better off as GRASS
variables; this would allow them to be controlled through modules,
rather than requiring the user to set them on the command line.
That's right, some of them started as shell variables (GRASS_GUI) and
later became GRASS variables (e.g. GRASS_GUI) without changing the
variable name. Manual page variables.html became quite outdated by
time. I would incline to minimalize shell variables if possible. Could
we collect minimal group of shell variable which we need?
The downside is that scripts (and wxGUI) would need to create a
temporary $GISRC file rather than just using a modified environment.
It's also related to the recently re-implemented d.mon in G7. Monitors
in G6 are basically executables running on the background. I would not
personally backport these monitors to G7. Currently d.mon G7 creates
supporting files which are tracked as GRASS variable, eg.
and MONITOR_wx0_CMDFILE contains list of display commands (used by
`d.mon -c` or `d.redraw`).
d.mon stop=wx0
removes these GRASS variables, similarly work other display drivers,
eg. `d.mon start=ps output=nc.ps`
This solution is completely based on usage supporting files which
defines output and env variables for rendering. Downside is that env
file is read everytime when is D_open_driver() called, ie. when
running d.* command.
> Note that 6.x also understands e.g. "GRASS_RENDER_IMMEDIATE=PS" (the
> only "immediate" drivers available in 6.x are PNG and PS; others
> require the use of a monitor).
>
> IOW, the usage is the same in 6.x and 7.0, except that 7.0 doesn't
> recognise "FALSE" (you'll just get the default driver; cairo if it's
> available, PNG otherwise).
AFAIU all display drivers in G7 are "immediate", monitors as
implemented in G6 has been removed in G7. Right?
Right. Hence GRASS_RENDER_IMMEDIATE=FALSE not being valid.
> Some of these environment variables might be better off as GRASS
> variables; this would allow them to be controlled through modules,
> rather than requiring the user to set them on the command line.
That's right, some of them started as shell variables (GRASS_GUI) and
later became GRASS variables (e.g. GRASS_GUI) without changing the
variable name. Manual page variables.html became quite outdated by
time. I would incline to minimalize shell variables if possible. Could
we collect minimal group of shell variable which we need?
The only ones which absolutely have to be environment variables are
those which are used by code which isn't part of GRASS, e.g. PATH,
LD_LIBRARY_PATH, PAGER, etc. Plus GISRC, obviously.
For anything which is part of GRASS, it's our choice as to whether to
use environment variables or $GISRC variables.
For anything which is part of GRASS, it's our choice as to
whether to use environment variables or $GISRC variables.
still, for running the PNG and PS drivers from the command line
or scripts, I'd rather not have to create a dummy GISRC file
each time, as it would be a lot more work.
which variables exactly would be better controlled by modules
directly? (eg FONT needs to be unique per-module not per-monitor,
but GRASS_WIDTH,HEIGHT are unique per-monitor)
> For anything which is part of GRASS, it's our choice as to
> whether to use environment variables or $GISRC variables.
still, for running the PNG and PS drivers from the command line
or scripts, I'd rather not have to create a dummy GISRC file
each time, as it would be a lot more work.
which variables exactly would be better controlled by modules
directly?
Anything where you want the user to be able to change the setting via
a module rather than requiring the user to use "export" or "eval `...`".
> Hamish wrote:
> > which variables exactly would be better controlled by
> > modules directly?
Glynn:
> Anything where you want the user to be able to change the
> setting via a module rather than requiring the user to use
> "export" or "eval `...`".
I ask because I'm having trouble imagining examples.
If you want something like d.mon with GRASS 7, then the driver-related
environment variables need to be moved to a file.