[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