No subject

remain functional, but to inhibit the execution of new commands
(except those which are always safe, e.g. g.manual) than to simply
"hang" until the command completes. However, implementing that would
be non-trivial; you would need to start all commands in the
background, then manually check for termination (and I have no idea
how to do that in Tcl).

And the ideal, i.e. only allowing further commands to be run if they
are "compatible" with outstanding commands is, I suspect, so complex
as to be practically impossible.

> Ideally, it would be nice if there we only needed 2 ways to run a GRASS
> command from tcltkgrass: 1) the command runs via a G_gui() autogenerated
> dialog and/or output is returned to a tcltk window; and 2) the command runs
> in an xterminal (distinct from the GRASS shell terminal) and output is
> directed to the same terminal.

That doesn't account for the situation where the command needs no
arguments (or the menu entry includes specific arguments, e.g. the
start/stop/select monitors entries) and performs no interaction. I
suppose that you could force it into the G_gui() mould, i.e. a dialog
with zero arguments.

> Currently, there are only a small percentage
> of the GRASS commands that fall into category 2. The rest work fine with the
> execute procedure. Can the execute procedure be augmented to permit commands
> with arguments that normally run via G_gui to be processed?

AFAICT, if you supply one or more arguments on the command-line,
G_gui() (or the old interactive() if GRASS_UI_TERM is set) is never
called. So I can't see any point in allowing the "execute" procedure
to accept arguments (it would be trivial to support, though).

That reminds me; there's a subtle issue regarding d.what.*: if one or
more maps (of the correct type) are displayed on the monitor, it won't
call into G_gui() even if no arguments are supplied. Whilst this is
convenient if this was what you actually wanted, it essentially means
that it won't offer you the option to provide arguments via a dialog.

A similar issue applies to commands for which all arguments are
optional (e.g. d.erase). I guess that we need a switch (or environment
variable) which will force the use of G_gui() even when a command can
be run with no arguments.

-- 
Glynn Clements <glynn.clements at virgin.net>