[GRASS-dev] TCL/TK GUI development questions answered

Michael,

Here's a quick one (I think). How do I 'break into' gronsole in order to
send some information there? What I want to do is the following. I've
already set up bindings on the points to store the current xy geographic
coordinates to a variable each time you click on a display with a mouse.
I'd just like to be able to send this information to the gronsole. This is
a wish someone made sometime back and it seems like a good idea. But in my
initial look at the gronsole code, it was unclear to me where I could
insert this information in order for it to be displayed.

This one I can handle. Short answer in gis.m (these are implemented at the
bottom of runandoutput.tcl):

Say we start clicking and want to print a list of points.
set handle [monitor_annotation_start $mon "Click Lister Tool" [list gism]]

Then later when someone clicks we'd do this to add the location to the list:
monitor_annotate $handle "$x $y \n"
(pardon me if that isn't really variable substitution in a string and a
newline, I've been a while from tcl/tk)

If we have a little icon for the tool (status-clicktool.gif), we can add it to
the horizontal bar like so. I've also taken the liberty of lifting the title
string for translation:

set handle [monitor_annotation_start $mon [G_msg "Click Lister Tool"] [list
gism clicktool]]
($mon is that annoying monitor variable, it's not used in the current
implementation...)

This extra abstraction is probably preferred for all of gis.m.

The long answer is...

There are two gronsole methods, annotate and annotate_text. Annotate makes a
new program header, and annotate_text adds fake output. Assuming that
$gronsole is a path command of a gronsole then you can do things like this:

set handle [$gronsole annotate [G_msg "Click Lister Tool"] [list gism
clicktool running]
$gronsole set_click_command $handle {}

The second command makes clicking on the horizontal bar do nothing (instead of
recalling the command so it can be run again, which makes no sense here)

Then when you get clicks you can:
$gronsole annotate_text $handle "$x $y \n"

And then when the tool's use is discontinued you can

$gronsole remove_tag $handle running
$gronsole add_tag $handle success

These behaviours could be easily wrapped up in runandoutput.tcl if they are
needed.

On the other hand, in general, I'm trying to wind down the new features for
the TclTk GUI and make sure it is robust and stable so that it can hang
around for a year or so with only minor maintenance. That should give us
all a chance to start working on the new wxPython GUI in earnest. Because
of looming health issues that may make my contributions sporadic for
awhile, I've sent my current wxPython files to Jachym Cepicky, who can
coordinate these efforts for awhile. I hope you are interested in
contributing.

The current remaining work on TclTk involves trying to improve the startup.
I've done a lot of fixing to the EPSG startup. I'm waiting on changes to
g.proj to do the same with the georeferenced file part. The code for the
main startup screen is nearly prehistoric, making it difficult to work
with. It needs more improvements, but I'm not sure how much is worth it.

The other thing is bringing NVIZ up to date. I've done a lot on that front
lately. Most of it is done--at least cosmetically. The code structure is
pretty out of date, but I've fixed the worst of it. Like the entry panels,
NVIZ generally lacks namespace definitions and has far too many globals,
which cause a number of problems. But it would be an enormous task to
rewrite all the procedures to respect local namespaces. I was working with
Hamish Bowman and Bob Covill to improve the north arrow and scale tools. We
are almost there, needing some additional C-coding and debugging to make
the font setting work. Also need to improve the looks of the scale and the
spatial relationships between arrow/"N" and scale/key. The TclTk part is
virtually done, with stubbed variables awaiting Bob. Finally, the advanced
animation panel (formerly misnamed as keyframe animation--both are keyframe
animation) is semi-broken. The code is a mess. I managed to untangle it all
and make it work pretty nice in the simple animation panel, but haven't had
time to fight my way through the other panel.

It seemed to me, when I discontinued active development this summer, that the
next obvious direction would be a unified layer compositing (2D) and on-mesh
display system (3D), for use both as a gui component and as an output method.
I had some ideas, and played around a bit with pygame (for OpenGL), but I had
neither the time nor the hardware to pursue it.

If anyone has an excuse to hire me and a machine with a graphics accelerator
I'd be thrilled to develop a new grass gui.

So if any of these items seem like an enjoyable challenge, dig in. Maybe
let me know what you're up to so that we don't work at cross-purposes. All
the best.

Hopping over to the grass list,

Cedric