On Fri, 27 Jul 2007, Thomas Adams wrote:
Michael,
Thanks for taking the time for the thoughtful responses. I very much want to
contribute and I think I can it's more a matter of finding the time (as I'm
sure it's true for you and others). I don't know Tcl/Tk, but I'm sure I could
mess around and do OK (I do my programming in Perl & C mostly, but also
*some* simple shell scripting). My programming background includes X Window
System & Motif
I think you should be able to use *any* GUI toolkit that includes the
concept of a "canvas" - you can use GRASS d.* commands to create maps and
write the output to a PNG or PostScript file, then load this into the
canvas widget in the GUI you have created. This is how the GRASS GUIs work
and it's very fast (the time taken to load the image is tiny compared to
the time taken for GRASS to generate it). Whichever GUI toolkit you're
using should have facilities to collect user-clicked points from the
canvas - e.g. a user could draw a shape on the screen and you could
collect these co-ordinates and pass them to v.in.ascii (run in the
background) to generate a vector map, then overlay the vector on the
original image (running d.rast and d.vect in the background, outputting
the image to a file) and load the resulting image back into the canvas
widget. All this would be totally seamless to the user and take only a
second or two. The same for text labels collected from the user through
the GUI and then overlaid on the map using the d.text command and that
kind of thing.
I have close to zero GUI-programming experience, but I hope I haven't got
the basic concepts wrong here - what I'm trying to say is you're not
limited to adapting any of the current GRASS GUIs - all they basically are
is a canvas widget with a few menus passing pass data in and out of GRASS
commands running "behind the scenes". None of the current GUIs interface
directly to GRASS in C - it is a much simpler interface than that, but in
general this is a strong point: you can use any scripting language and any
GUI toolkit.
I think this is the point Michael was making about how the GUI is a really
simple layer on top of the GRASS commands, and if your GUI needs are
pretty simple - drawing shapes on a map and adding text annotations, for
example - it may be much less work implementing it from scratch in your
favourite scripting language/GUI toolkit rather than trying to familiarise
and adapt one of the existing GRASS GUIs (e.g. d.m, gis.m or wxGRASS) - I
hope I haven't made it more confusing!
Paul
_______________________________________________
grassuser mailing list
[email protected]
http://grass.itc.it/mailman/listinfo/grassuser
