[GRASS5] embedding GRASS display into my app

[Glynn Clements]

David Piasecki wrote:

> I want to write an application that uses GRASS as the back end to an 
> application I plan to write. I need to embed the GRASS display into my 
> application. I haven't started yet, though C++ would be easiest for me. 
> If I have to learn Tcl/Tk, that's fine too. From what I understand, I 
> should be able to modify the XDRIVER in GRASS to handle events in my 
> application's main window, and I should be able to use TkSteal to 
> actually embed the graphics display for GRASS into my application's 
> main window. I'm not exactly clear on how to do all this considering 
> I'm new to GRASS and Tcl/Tk. I found a paper online saying it has been 
> done, but I haven't heard of anyone else that's done it, and I haven't 
> seen any documentation on how to do it. Any help you could provide 
> would be greatly appreciated.

XDRIVER can be made to use an existing X window by setting the
environment variable XDRIVER_WINDOW to the XID of the existing window. 
The value can be in any format acceptable to sscanf("%i"), i.e. 
decimal, hex preceded by "0x", or octal preceded by "0".

However, note that X doesn't allow multiple clients to select
ButtonPress events for a given window, so the Get_location_with_*
functions (used by d.where, d.what.* etc) won't work if those events
have already been selected by the program which creates the window.

An alternative approach for a front-end would be to use the PNG driver
for all graphical output, and have your program display the PNG
images.

This is likely to be somewhat tidier than either embedding the XDRIVER
window (which is highly X-specific; this won't work with e.g. the
"generic" Windows port), or trying to use the XDRIVER code (which uses
the "raw" Xlib API).

It is also more flexible. E.g. if you want to support "layers",
rendering each layer as a separate PNG file then composing them in
your program may be preferable to re-rendering the entire set whenever
a layer is added, removed or changed.

-- 
Glynn Clements <glynn.clements at virgin.net>