Michael, fellow developers,
I found some undesirable behaviors in the way output is displayed in the GUIs.
The output routines (copied and pasted) between programs do the following:
Drop one line of text when a pipe blocks.
Generate a tk update for every line of text until a pipe blocks.
Don't read all input until the pipe blocks, garanteing that running programs
like v.in.ogr will block over and over again.
I have written a "gronsole" widget that is a wrapper around a text box. It
will run programs in a small variety of ways (waiting for completion,
not-blocking, in an xterm, just an annotation) and display both the history
and the formatted output with images and so-on. This collects most of the
program execution and output code in one place. Headers for commands in the
history have icons for tagging them (such as being run by gis.m, currently
running, etc), buttons to hide and display that command's output (making for
a terse history) and remove the command from the history, and can have a
command bound to clicking on the command text or icon.
I have dropped it into gui.tcl. This makes almost no change, except the proc
prnout is no longer needed, and output is formatted very slightly
differently.
I left d.m alone. It only experiences the changes to programs run by gui.tcl
I have also wired it up to gis.m by moving all of the spawn, execute, runcmd,
run_panel, etc code into a new file, and replacing them, where appropriate,
with calls to a "gronsole" widget. This makes a new window that replaces the
output display with save and clear buttons, a "gronsole", a text box for
typing in commands, run buttons and a button to open up the gui.tcl widget
for the currently edited command. Clicking on headers for commands in the
history copies the command into the current command box. When commands are
run from the menus in gis.m the command and its output are added to the
history in the general gis.m output window.
I think there are a few other changes that should be made to gis.m. I don't
think we should source gui.tcl etc in every single .tcl file. I think we
should make one proc that handles copying files from the current output to
the temporary folder. I think this new command should add an annotation to
the output log so that the actual sort of commands needed to produce the
output gis.m produces are clear to the user. Eventually it would be nice to
do this in a small module to make command line usage of the composite program
easy.
I'd also like to, eventually, have a way of using the gui.tcl widgets in
command type layers. I need to understand more of how the layer system and
tree works before approaching this.
--Cedric Shock