[GRASS5] Need testers for tcltkgrass update for 5.7

[Michael Barton]

Glynn,

Thanks for the very useful input. I tried your modification and they work
just fine under Mac OS X. Looking at your new procedures for calling
programs and doing a bit of experimentation has led to a few questions.

On 8/17/04 5:43 PM, "Glynn Clements" <glynn.clements at virgin.net> wrote:

> 
> Michael Barton wrote:
> 
>> I'll check this version on my Mac also and look it over. I'll wait to commit
>> this until I hear back from Moritz (or anyone else who wants to weigh in on
>> this). I need to understand which commands need which of the spawn, run, and
>> term procedures and why.
> 
> Well, in general, anything which performs interaction on the terminal
> needs to use "term", anything else which runs indefinitely needs to
> use "spawn", and the rest (i.e. anything which isn't interactive and
> which doesn't run indefinitely) can use "run".

OK. I understand this distinction and can see what the differences are
between the execute, spawn, and run procedures.

But now I suppose I betray my ignorance. If I call a normal GRASS 5.7
command with no argument (i.e., it is parsed by G_gui() and autogenerates an
interactive tcltk dialog) through either the spawn or run procedures it
*appears* to work the same as if I called it via the execute procedure. Is
there a problem in doing this? Why can't I just use run, for example, to
call all GRASS programs except those that require an xterm?

> 
> The "runs indefinitely" is actually quite tricky. Primarily because
> running multiple GRASS programs concurrently is problematic. If you
> start a long-running program such as v.digit, it's debatable whether
> you should be allowed to run anything else until it finishes.
> 
> From the perspective of neatness, it would be better for the UI to
> 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.

Is the possibility of running incompatible commands really a potential
problem? If so, maybe there is a way around it and satisfying at least some
of the conditions you mention above. I've not yet run into this kind of
incompatibility probably because in actually working with GRASS, I often
'run' several commands, but then leave them 'paused' at the opening dialog.
I then switch back and forth between commands so that I am actually running
only a single command at a time, rather than running them concurrently in
the full sense. I suspect that this is what most people do most of the time.

Under such circumstances, could pressing the 'run' button on the dialog box
also inhibit the execution of other commands except for 'safe' ones? If so,
this would work for most commands, I think, without compromising the
functionality of the UI. Notable exceptions would be d.m, d.mon, and nviz.

> 
>> 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).
> 


Hmm. But it seems that commands without arguments can 'run' or 'spawn' like
commands that need arguments and still manage to go through G_gui(). Given
this, is there still a need for the 'execute' procedure?

If I call a GRASS command via the command line shell, it is somehow parsed
correctly--going to a G_gui() dialog or an interactive xterm if there are no
arguments, or performing its function if there are arguments. Is it a
limitation of tcltk that prevents this parser (i.e., that correctly routes
different kinds of calls from the command line) from operating in the same
way in this context? Sorry if I'm being dense, but this discussion has been
very helpful in better understanding how this operates.


> 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.

Double hmm. I'd never noticed this before. Perhaps this issue is connected
to the reason that d.what.vect give a 'broken pipe' error after the 2nd time
it is run in a GRASS session unless you force it to xterm mode with -x.

> 
> 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.

It would indeed be nice to have greater consistency in how commands need to
be called.

Thanks again for your help.

Michael
____________________
C. Michael Barton, Professor
School of Human Origins, Cultures, & Societies
PO Box 872402
Arizona State University
Tempe, AZ  85287-2402
USA

Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>