[GRASS5] Re: General and gis.m module running (stdout,stderr,exit status) issues

[Cedric Shock]

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 
examples:

execute g.region
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.

Pondering,

--Cedric