[GRASS5] Re: General and gis.m module running (stdout,stderr,exit status) issues
cedricgrass at shockfamily.net
Mon Apr 3 19:38:46 EDT 2006
Michael, Markus, Glenn, and everyone,
> Is this the syntax to put into the menu item? (execute [command] --ui ???)
execute runs the program with the --tcltk switch and sources the response, so
it will always get a user interface. The syntax to put into the menu item
depends on how we sort out the need for xmons and xterms (see below). Adding
xmon and xterm flags to execute might be a neat syntax like in these
execute v.digit xmon
execute v.query xmon xterm
execute g.setproj xterm
> For v.digit, I thought it might be how I tried to work it through gis.m, so
> I tried running it from the command line and was still having problems.
> Several programs (e.g., v.digit, d.profile) won't run unless there is an
> open xmon. The old gis.m tried to help by opening an xmon before starting
> one of those programs. People can simply do the whole thing manually, but
> this can be complicated for newish users.
I actually like having gis.m try to open a monitor for them. It just needs to
work, and probably be independent of the method used to run the program. I
think the appropriate logic for opening one would be something like this:
If there's a running selected x display do nothing.
Otherwise start and select the last (or first) not started x display.
If there's no available (not running or running and selected) x display then
do nothing and let the module report an error.
> One thing I just thought of that might be a good idea in general at this
> juncture. For the few modules that require an xterm for display, is there
> some way to build in a button (referenced in the C code lines that format
> the module gui) that can be used to start an xterm? Or is running anything
> like this through parser.c problematic at the moment?
This is actually done in the tcl code of gui.tcl, not in c. I made a "Run in
xterm" button that's part of the gis.m console ui; it wouldn't be hard to add
one to gui.tcl.
A better approach would be to add something to module descriptions that
requests/demands an interactive terminal. Then gui.tcl and the execute proc
in gis.m could automatically run anything needing an xterm that way instead
of in the "gronsole". This would require a small change to gis.h, parser.c,
g.parser and to every one of those programs to set "needs an interactive
terminal" to true.
Alternatively, and more in line with what you or someone before was doing in
gmmenu.tcl, we could make a list of programs that need an xterm and do all of
this in tcl. This would require a change to SUBMITTING. It would probably
also need some connection to GEM (of which I know nothing) so that extension
modules can report themselves as needing xterms; in this way changing gis.h
etc. might be better. If GEM has commands for menu listings just like ours
then changing execute as described above will solve it all.
The slickest solution of all is to make "gronsole" into a happy terminal
emulator so that everything just works. This is probably outside of what's
feasible for us to do.
More information about the grass-dev