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

[Michael Barton]

On 5/11/07 5:32 PM, "Glynn Clements" <glynn at gclements.plus.com> wrote:

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

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.

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

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

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.

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