[GRASS-dev] Re: not quite there on fonts

Glynn Clements glynn at gclements.plus.com
Fri May 11 20:32:01 EDT 2007


Michael Barton wrote:

> > There's no need. gis.m could leave GRASS_RENDER_IMMEDIATE set to TRUE
> > at all times, and only unset it when spawning a child process which is
> > going to use an X monitor.
> 
> OK. I've changed the TclTk GUI to set GRASS_RENDER_IMMEDIATE to TRUE when it
> starts, and have taken the setting/unsetting of this variable out of the
> display routine. The font selection works again.
> 
> Given what you say above, can I set all of these for the GUI session and not
> worry about their impact on how grass functions from the command line during
> that session?
> 
>     set env(GRASS_BACKGROUNDCOLOR) "ffffff"
>     set env(GRASS_TRANSPARENT) "TRUE"
>     set env(GRASS_PNG_AUTO_WRITE) "TRUE"
>     set env(GRASS_TRUECOLOR) "TRUE"

You can set any environment variables in gis.m, without risk of them
affecting the shell (or any other process not spawned from gis.m).

The only issue is that, if gis.m still has the ability to spawn
commands which use a monitor (i.e. the guarantee_xmon scenario), you
must unset GRASS_RENDER_IMMEDIATE before spawning such a command.

> > With Python, the situation is better, as the Popen constructor allows
> > you to specify an explicit environment for each process. Tcl lacks
> > this, so you have to modify your own environment and let the child
> > inherit it.
> 
> Can we just set the environment at the beginning of the wxPython GUI session
> (i.e., in the init for the original gis manager frame in wxgui.py)? Or do we
> need to include a Popen somehow when the GUI is launched?

If you use Popen objects for command spawning, you can pass a
completely separate environment via the constructor's "env" parameter,
e.g.:

	newenv = os.environ.copy()
	newenv.update({"GRASS_RENDER_IMMEDIATE" : "TRUE"})
	subprocess.Popen(..., env=newenv)

Personally, I would suggest doing that rather than modifying wxgui's
own environment (os.environ).

That allows you to set environment variables for a child process
without having to set them back afterwards. It also makes it
straightforward to pass different environments to different types of
child process (e.g. one for display commands, another for
"computation" commands).

-- 
Glynn Clements <glynn at gclements.plus.com>




More information about the grass-dev mailing list