[GRASS-dev] Re: [GRASS-user] GRASS "custom" applications

[Paul Kelly]

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