[GRASS-dev] not quite there on fonts

[cmbarton]

I just updated a Mac in the lab. d.font –l returns nothing, which makes the font list empty in the GUI. I tried manually running g.mkfontcap with a couple of different option. g.mkfontcap is indeed doing its thing, putting stuff into fontcap and freetypecap. But d.font is not reading it.

Michael

---

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

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

[Paul_Kelly]

On Fri, 11 May 2007, Michael Barton wrote:

I just updated a Mac in the lab. d.font ­l returns nothing, which makes the
font list empty in the GUI. I tried manually running g.mkfontcap with a

Does it work OK if you start a monitor first (d.mon x0)? I think, because of the way it now uses R_* functions it depends in some way on having some valid display output working. From the commandline on Linux I noticed too it outputs nothing, but when I set GRASS_RENDER_IMMEDIATE=TRUE first then it outputs the list. On Windows the list showed up fine. So I was assuming that gis.m must have set GRASS_RENDER_IMMEDIATE=TRUE and thus everything was OK. Maybe there's something else on Windows that causes GRASS_RENDER_IMMEDIATE=TRUE to be set? Or maybe I'm barking up the wrong tree?

couple of different option. g.mkfontcap is indeed doing its thing, putting
stuff into fontcap and freetypecap. But d.font is not reading it.

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

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

[cmbarton]

Well, this is a clue indeed.

If I open an xmon (d.mon x0), d.font -l makes a nice list of fonts and these
even show up in the gui.

If I close the xmon, d.font -l shows nothing (and the nice font list goes
away).

GRASS_RENDER_IMMEDIATE is set to TRUE in the GUI, but that doesn't seem to
make any difference.

Michael

On 5/11/07 10:33 AM, "Paul Kelly" <paul-grass@stjohnspoint.co.uk> wrote:

On Fri, 11 May 2007, Michael Barton wrote:

I just updated a Mac in the lab. d.font ­l returns nothing, which makes the
font list empty in the GUI. I tried manually running g.mkfontcap with a

Does it work OK if you start a monitor first (d.mon x0)? I think, because
of the way it now uses R_* functions it depends in some way on having some
valid display output working. From the commandline on Linux I noticed too
it outputs nothing, but when I set GRASS_RENDER_IMMEDIATE=TRUE first then
it outputs the list. On Windows the list showed up fine. So I was assuming
that gis.m must have set GRASS_RENDER_IMMEDIATE=TRUE and thus everything
was OK. Maybe there's something else on Windows that causes
GRASS_RENDER_IMMEDIATE=TRUE to be set? Or maybe I'm barking up the wrong
tree?

couple of different option. g.mkfontcap is indeed doing its thing, putting
stuff into fontcap and freetypecap. But d.font is not reading it.

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

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

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

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

[Paul_Kelly]

On Fri, 11 May 2007, Michael Barton wrote:

Well, this is a clue indeed.

If I open an xmon (d.mon x0), d.font -l makes a nice list of fonts and these
even show up in the gui.

OK. I was just thinking, it is logical that you have to have a display driver open (or at least indicate which one you are going to use) before d.font can list the fonts, because the list might depend on which display driver you are using. E.g. the possible future support for PostScript built-in fonts that Glynn mentioned.

GRASS_RENDER_IMMEDIATE is set to TRUE in the GUI, but that doesn't seem to
make any difference.

But is it set at the point d.font is run, or is it only set after that?

gis.m uses direct rendering for all output, doesn't it, so it should be safe to always have GRASS_RENDER_IMMEDIATE set, I think... ?

Paul

[cmbarton]

On 5/11/07 11:05 AM, "Paul Kelly" <paul-grass@stjohnspoint.co.uk> wrote:

On Fri, 11 May 2007, Michael Barton wrote:

Well, this is a clue indeed.

If I open an xmon (d.mon x0), d.font -l makes a nice list of fonts and these
even show up in the gui.

OK. I was just thinking, it is logical that you have to have a display
driver open (or at least indicate which one you are going to use) before
d.font can list the fonts, because the list might depend on which display
driver you are using. E.g. the possible future support for PostScript
built-in fonts that Glynn mentioned.

GRASS_RENDER_IMMEDIATE is set to TRUE in the GUI, but that doesn't seem to
make any difference.

But is it set at the point d.font is run, or is it only set after that?

gis.m uses direct rendering for all output, doesn't it, so it should be
safe to always have GRASS_RENDER_IMMEDIATE set, I think... ?

Paul

GRASS_RENDER_IMMEDIATE is set prior to rendering and unset immediately
after. The reason is that it doesn't affect any command-line use of GRASS.

Michael

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

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

[Paul_Kelly]

On Fri, 11 May 2007, Michael Barton wrote:

GRASS_RENDER_IMMEDIATE is set prior to rendering and unset immediately
after. The reason is that it doesn't affect any command-line use of GRASS.

So you're saying if you start a Tcl application (e.g. gis.m) from a Unix shell, and then set an environment variable within the Tcl application, that the shell kind of inherits it backwards and commands run from there will be affected by the changed environment? I didn't think of that - I suppose it would be better if Tcl allowed you to specify environment variables that applied only to it and commands spawned from it.

But I suppose anyway you can work around it in this case by setting GRASS_RENDER_IMMEDIATE before running d.font -l and unsetting it afterwards.

Paul

[cmbarton]

On 5/11/07 11:41 AM, "Paul Kelly" <paul-grass@stjohnspoint.co.uk> wrote:

On Fri, 11 May 2007, Michael Barton wrote:

GRASS_RENDER_IMMEDIATE is set prior to rendering and unset immediately
after. The reason is that it doesn't affect any command-line use of GRASS.

So you're saying if you start a Tcl application (e.g. gis.m) from a Unix
shell, and then set an environment variable within the Tcl application,
that the shell kind of inherits it backwards and commands run from there
will be affected by the changed environment? I didn't think of that - I
suppose it would be better if Tcl allowed you to specify environment
variables that applied only to it and commands spawned from it.

But I suppose anyway you can work around it in this case by setting
GRASS_RENDER_IMMEDIATE before running d.font -l and unsetting it
afterwards.

Just tried this and it doesn't work. When I set GRASS_RENDER_IMMEDIATE and
run d.font -l, it tries to generate a PNG file from the font list. This
generates an error of course.

Michael

Paul

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

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

[Paul_Kelly]

On Fri, 11 May 2007, Michael Barton wrote:

On 5/11/07 11:41 AM, "Paul Kelly" <paul-grass@stjohnspoint.co.uk> wrote:

On Fri, 11 May 2007, Michael Barton wrote:

GRASS_RENDER_IMMEDIATE is set prior to rendering and unset immediately
after. The reason is that it doesn't affect any command-line use of GRASS.

So you're saying if you start a Tcl application (e.g. gis.m) from a Unix
shell, and then set an environment variable within the Tcl application,
that the shell kind of inherits it backwards and commands run from there
will be affected by the changed environment? I didn't think of that - I
suppose it would be better if Tcl allowed you to specify environment
variables that applied only to it and commands spawned from it.

But I suppose anyway you can work around it in this case by setting
GRASS_RENDER_IMMEDIATE before running d.font -l and unsetting it
afterwards.

Just tried this and it doesn't work. When I set GRASS_RENDER_IMMEDIATE and
run d.font -l, it tries to generate a PNG file from the font list. This
generates an error of course.

Did you update gis.m from CVS first? d.font -l needs to have its stderr redirected (as should probably most commands run in the background like this - thinking of all the problems with g.region calls). I updated it in
CVS to do this today - seem my earlier e-mail to Glynn explaining why.

Basically the list of fonts is dependent on the driver being used. So d.font needs to open the driver first before listing the fonts. In the case of direct rendering and the PNG driver, as Glynn said that results in some messages being printed to stderr. It doesn't mean d.font is trying to create an image though - just the process it has to go through before it can list the fonts.

Hope that is a clearer explanation.

Paul

[Glynn_Clements1]

Paul Kelly wrote:

On Fri, 11 May 2007, Michael Barton wrote:

> GRASS_RENDER_IMMEDIATE is set prior to rendering and unset immediately
> after. The reason is that it doesn't affect any command-line use of GRASS.

GRASS_RENDER_IMMEDIATE is an environment variable.

Every process has its own set of environment variables. Setting
$env(GRASS_RENDER_IMMEDIATE) in gis.m will only affect processes which
are spawned by gis.m; it can't affect those run from the shell.

Paul Kelly wrote:

So you're saying if you start a Tcl application (e.g. gis.m) from a Unix
shell, and then set an environment variable within the Tcl application,
that the shell kind of inherits it backwards and commands run from there
will be affected by the changed environment?

I suppose that's what he was thinking, but that's incorrect.

The environment is part of a process' address space. Every process has
its own environment. The environment is duplicated along with the rest
of the address space by fork(), while execve() takes the environment
as an argument. The other exec* functions are all wrappers around
execve(); those without the "e" suffix simply pass the existing
environment.

IOW, a child process will normally inherit its environment from its
parent; thereafter, a process can modify its own environment, but not
the environment of another process.

I didn't think of that - I
suppose it would be better if Tcl allowed you to specify environment
variables that applied only to it and commands spawned from it.

But I suppose anyway you can work around it in this case by setting
GRASS_RENDER_IMMEDIATE before running d.font -l and unsetting it
afterwards.

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.

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.

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

[Glynn_Clements1]

Michael Barton wrote:

If I open an xmon (d.mon x0), d.font -l makes a nice list of fonts and these
even show up in the gui.

If I close the xmon, d.font -l shows nothing (and the nice font list goes
away).

GRASS_RENDER_IMMEDIATE is set to TRUE in the GUI, but that doesn't seem to
make any difference.

If the behaviour of "d.font -l" within the GUI varies depending upon
whether or not an X monitor is running, then
env(GRASS_RENDER_IMMEDIATE) isn't actually set to TRUE at the point
that "d.font -l" is executed.

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

[cmbarton]

On 5/11/07 1:23 PM, "Glynn Clements" <glynn@gclements.plus.com> wrote:

So you're saying if you start a Tcl application (e.g. gis.m) from a Unix
shell, and then set an environment variable within the Tcl application,
that the shell kind of inherits it backwards and commands run from there
will be affected by the changed environment?

I suppose that's what he was thinking, but that's incorrect.

That's not what I meant, but the rest of this is helpful anyway.

The environment is part of a process' address space. Every process has
its own environment. The environment is duplicated along with the rest
of the address space by fork(), while execve() takes the environment
as an argument. The other exec* functions are all wrappers around
execve(); those without the "e" suffix simply pass the existing
environment.

IOW, a child process will normally inherit its environment from its
parent; thereafter, a process can modify its own environment, but not
the environment of another process.

I didn't think of that - I
suppose it would be better if Tcl allowed you to specify environment
variables that applied only to it and commands spawned from it.

But I suppose anyway you can work around it in this case by setting
GRASS_RENDER_IMMEDIATE before running d.font -l and unsetting it
afterwards.

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"

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?

Michael

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

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

[Glynn_Clements1]

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@gclements.plus.com>

[cmbarton]

On 5/11/07 5:32 PM, "Glynn Clements" <glynn@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

[cmbarton]

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

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.

Turns out it doesn't work to put this into the guarantee_xmon procedure, so
I inserted setting and unsetting GRASS_RENDER_IMMEDIATE into the menu entry
for the few commands that still need an xmon.

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

[Glynn_Clements1]

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@gclements.plus.com>

[cmbarton]

On 5/12/07 4:51 AM, "Glynn Clements" <glynn@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

[Glynn_Clements1]

Michael Barton wrote:

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

Yes.

Is this behavior why you don't seem to need a close statement
either?

If you're running the command asynchronously, there probably should be
a close() call. AFAIK, Python will do this automatically if and when
the Popen object is garbage-collected, but you can't be sure when that
will happen, so it's best to call close() explicitly once you're
finished with it.

If you're using a method which reads until EOF and returns the output
as a string, then that will probably perform the close() itself.

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

[Paul_Kelly]

On Fri, 11 May 2007, 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"

Interesting to see this - I guess this means there's no way to change the default background colour to anything other than white then? Was thinking this would be a useful setting for the GUI to have - e.g. I much preferred the default black background in GRASS <= 5, much easier on the eyes I thought.

I was also noticing (have been trying out d.histogram while experimenting with fonts recently) that it seemed a bit non-intuitive that to display a histogram you had to treat it as a map you were displaying and it appeared in the Map display Window, with the region setting controls, co-ordinate display, etc. all intact. I was thinking it might be more logical and look tidier if it appeared in a separate graph display window - the background colour could perhaps even be set to be the same as the normal Window background colour and it might look very neat then.

Maybe the new GUI does something like this already - I suppose I should be looking at it when commenting like this - this is neither a bug report or a wish, just a few thoughts I had that I thought I should write down!

Paul

   set env(GRASS_TRANSPARENT) "TRUE"
   set env(GRASS_PNG_AUTO_WRITE) "TRUE"
   set env(GRASS_TRUECOLOR) "TRUE"

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?

Michael

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

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

[cmbarton]

On 5/12/07 3:33 PM, "Paul Kelly" <paul-grass@stjohnspoint.co.uk> wrote:

Interesting to see this - I guess this means there's no way to change the
default background colour to anything other than white then? Was thinking
this would be a useful setting for the GUI to have - e.g. I much preferred
the default black background in GRASS <= 5, much easier on the eyes I
thought.

That an interesting idea. Since we can set the default font, it's not a bad
idea to be able to set the default background. Of course you can already set
the background for rasters.

I was also noticing (have been trying out d.histogram while experimenting
with fonts recently) that it seemed a bit non-intuitive that to display a
histogram you had to treat it as a map you were displaying and it appeared
in the Map display Window, with the region setting controls, co-ordinate
display, etc. all intact. I was thinking it might be more logical and look
tidier if it appeared in a separate graph display window - the background
colour could perhaps even be set to be the same as the normal Window
background colour and it might look very neat then.

This because all d.* commands (i.e., those that can be run
non-interactively) are treated conceptually by the TclTk GUI in the same way
they are treated in an xmon, as something that shows up in a graphics
window. A profile is the one exception, since I had to rebuild that
completely in TclTk (as d.profile is an interactive module that can't be
displayed in a TclTk canvas.

However, you'll be interested to learn that I've already done histogramming
in exactly the way you suggest for the new wxPython GUI. It seemed to me
also that it makes more sense to treat a histogram in a way that is visually
different from a map. So it appears in its own window. I'd like to set the
background, but it seems that it won't take any background color (I've tried
various ways to do this, including GRASS_BACKGROUNDCOLOR and nothing changes
the white background).

Scalebars and legends, along with user-placed text (as opposed to vector
labels), are also treated differently in the new GUI. They are treated as
decorative overlays that can be dragged and positioned interactively with
the mouse, rather than as map layers.

Maybe the new GUI does something like this already - I suppose I should be
looking at it when commenting like this - this is neither a bug report or
a wish, just a few thoughts I had that I thought I should write down!

Do take a look at the development GUI. This is the place where we can think
about new ways to offer interactive access to GIS functionality.

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

[cmbarton]

On 5/12/07 3:33 PM, "Paul Kelly" <paul-grass@stjohnspoint.co.uk> wrote:

On Fri, 11 May 2007, 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"

Playing around with this variable in wxPython, it doesn't seem to do much of
anything--probably because we need to set the background color of the
composited map (i.e., all layers) with g.pnmcomp. I *can* change *that*
color and it does give a new background. But I was getting odd results from
the maps when I changed transparancy. I wonder if it's possible for
g.pnmcomp to have a transparent background?

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