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

Cedric Shock cedricgrass at shockfamily.net
Thu Jan 4 19:41:53 EST 2007


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




More information about the grass-dev mailing list