[GRASS5] New gui.tcl generic user interface

[Glynn Clements]

Michael Barton wrote:

> > I don't understand why the command log is in the main window of gis.m. I have
> > never been interested in what it says. I don't know what the buttons across
> > the bottom do at all, except for clear and open output window. I'm obviously
> > completely ignorant of what that is all for, but I think that log, and the
> > progress bar (display progress is shown in the other window), and the buttons
> > should go with the output somehow, giving more room for the main event.
> 
> This is not just a command log anymore. It is a console for running
> commands. If you place your cursor on a command and press "run", it sends
> the command to the GRASS command parser. The idea is be able to run GRASS
> without x11. You can also save a selected command history to a text file to
> track what you've done or put it into a script. Because it is a TclTk text
> widget, the command console is fully editable--considerably easier than in
> an xterminal.
> 
> Currently, there are 2 limitations to the command console as a replacement
> for the xterminal. One is that running display commands is a little
> problematic, though that should be less of a problem as Glynn changes them
> to output PPM files. The second is commands that require interactive input
> in an xterminal. It seems that there should be some way around this, but I
> haven't found it yet.

There are three types of interactive commands:

1. Commands which need stdin/stdout.
2. Commands which need a terminal (i.e. isatty() returns non-zero).
3. Commands which need a curses-compatible terminal.

The first issue for #1 is that Tcl's "open" command doesn't allow both
read and write access (popen() behaves the same way); I suspect that
this is because it's too easy to deadlock.

If the application is writing to the command's stdin, it probably
isn't reading from its stdout. If the output pipe fills up, the
command will block until it is no longer full, so it stops reading
from its stdin, so the input pipe fills, and the application blocks.

To support "slave" commands, you need to use non-blocking I/O or
threads, so that the output pipe is continuously being drained even
when the application is writing to the input pipe.

Once that's dealt with, supporting #2 would require the ability to
create pseudo-terminals. Tcl doesn't have this functionality built in,
so you would need a helper utility.

Supporting #3 would also require implementing a character-cell
terminal in Tcl/Tk, which would be a fair amount of work.

The ideal solution is to remove interaction from the individual
modules and put it in the GUI instead.

-- 
Glynn Clements <glynn at gclements.plus.com>