GRASS_RENDER_IMMEDIATE in GRASS7

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

GRASS_RENDER_IMMEDIATE in GRASS7

Martin Landa
HI,

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.

Any opinions?

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: GRASS_RENDER_IMMEDIATE in GRASS7

Glynn Clements

Martin Landa wrote:

> 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.

--
Glynn Clements <[hidden email]>
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: GRASS_RENDER_IMMEDIATE in GRASS7

Martin Landa
Hi,

2011/7/8 Glynn Clements <[hidden email]>:

>> 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.

That's right. Any opinion from other GRASS devs?

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: GRASS_RENDER_IMMEDIATE in GRASS7

Martin Landa
Hi,

2011/7/17 Martin Landa <[hidden email]>:

[...]

>> 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.

d.mon wx0
g.gisenv -n | grep MONITOR_wx0
MONITOR_wx0_ENVFILE=/home/martin/grassdata/nc_spm_08/PERMANENT/.tmp/pierre/7059.0.env
MONITOR_wx0_MAPFILE=/home/martin/grassdata/nc_spm_08/PERMANENT/.tmp/pierre/7059.0.ppm
MONITOR_wx0_PID=7060
MONITOR_wx0_CMDFILE=/home/martin/grassdata/nc_spm_08/PERMANENT/.tmp/pierre/7059.0.cmd

In this case MONITOR_wx0_MAPFILE defines GRASS_PNGFILE.

File MONITOR_wx0_ENVFILE contains rendering-related shell variables

cat /home/martin/grassdata/nc_spm_08/PERMANENT/.tmp/pierre/7059.0.env
GRASS_WIDTH=698
GRASS_REGION=n-s resol: 25.328330; n-s resol3: 10; rows: 533; north:
228500.0; t-b resol: 1; zone: 0; bottom: 0; rows3: 1350; west:
630000.0; top: 1; cols: 698; cols3: 1500; depths: 1; e-w resol:
21.489971; proj: 99; e-w resol3: 10; east: 645000.0; south: 215000.0;
GRASS_TRUECOLOR=TRUE
GRASS_PNG_READ=TRUE
GRASS_BACKGROUNDCOLOR=FFFFFF
GRASS_COMPRESSION=0
GRASS_TRANSPARENT=TRUE
GRASS_HEIGHT=533

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.

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: GRASS_RENDER_IMMEDIATE in GRASS7

Glynn Clements
In reply to this post by Martin Landa

Martin Landa wrote:

> > 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.

--
Glynn Clements <[hidden email]>
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: GRASS_RENDER_IMMEDIATE in GRASS7

hamish-2
Glynn wrote:
> 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)



Hamish

_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: GRASS_RENDER_IMMEDIATE in GRASS7

Glynn Clements

Hamish wrote:

> > 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 `...`".

--
Glynn Clements <[hidden email]>
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: GRASS_RENDER_IMMEDIATE in GRASS7

hamish-2
> 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.


thanks,
Hamish
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev
Reply | Threaded
Open this post in threaded view
|

Re: GRASS_RENDER_IMMEDIATE in GRASS7

Glynn Clements

Hamish wrote:

> > 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.

--
Glynn Clements <[hidden email]>
_______________________________________________
grass-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-dev