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

[Glynn Clements]

Michael Barton wrote:

> >> 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.
> 
> This is still necessary for a few commands. It seems like the most efficient
> way to deal with this is to build it into the guarantee_xmon procedure.

Don't forget to set it back again after the command has been started.

> It looks to me that GRASS_RENDER_IMMEDIATE is the only problematic one of
> these environmental commands for an xmon. Do you agree?

Yes. XDRIVER doesn't use any of the above.

> > 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).
> 
> This sounds like good advice, though I'm not quite sure where to insert
> this. Possibly in the command processor method in gui_utils.py. The other
> thing it how to set it back cleanly after the command is run.

The point is that you don't need to set anything back. You aren't
modifying os.environ itself, but modifying a copy and using the copy
as the child's environment.

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