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

Hamish hamish_nospam at yahoo.com
Sun May 13 07:45:17 EDT 2007


Glynn:
> > 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.
Michael:
> Turns out it doesn't work to put this into the guarantee_xmon
> procedure,

why not?

-command {guarantee_xmon; g.module }

Is guarantee_xmon (tcl proc) considered a child and enviro vars are not
global? Or you need to add an unset after the module in the -command?

do all guarantee_xmon fns also use term/spawn/grass-xterm-wrapper? It
should work if placed in grass-xterm-wrapper or grass-run.sh before the
"exec $@". As a bonus it would disappear when the module quits.


> so I inserted setting and unsetting GRASS_RENDER_IMMEDIATE into the
> menu entry for the few commands that still need an xmon.

for the record, there are 4 left.

grass63$ grep -A1 guarantee_xmon gui/tcltk/gis.m/gmmenu.tcl 
                        guarantee_xmon
                        term r.digit 
--
                        guarantee_xmon
                        term r.le.setup 
--
                        guarantee_xmon
                        spawn d.path.sh -b --ui
--
                guarantee_xmon
                term i.ortho.photo 

r.digit and d.path are probably low hanging fruit for a wx GUI
programmer (r.digit can be fully replaced with a new r.in.poly front-end
[it's just a crude r.in.poly front-end in the first place]; d.path is
non-interactive ready). r.le can be safely ignored for the new wx GUI,
as r.li matures. i.ortho.photo is harder, but IMO the GUI programmers
shouldn't worry about it until it gets its rewrite.


?
Hamish




More information about the grass-dev mailing list