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

[Michael Barton]

On 5/12/07 4:51 AM, "Glynn Clements" <glynn at gclements.plus.com> wrote:

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

I had to do this in the menu entry instead of guarantee_xmon because the
procedure calls the spawn to run the command.

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

Good. Thanks.

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

OK. So if there is need for a different environment for a child process, it
can be set in Popen and then you don't have to worry about it. Is this
behavior why you don't seem to need a close statement either?

Michael


__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton