[GRASS5] can't find GENERIC graphic driver in cvs trees

[Glynn Clements]

Jean-Denis Giguere wrote:

> I would like to do some experimentation with graphic driver. In GRASS 
> programmer manual, we can read that there is a directory called GENERIC 
> that contains basic routines. I can't find this direction in 5.3 nor 5.7 
> cvs tree.
> 
> Does someone know where can I find it ?

It doesn't exist in 5.0/5.3/5.7; it exists in 4.3.

> Is there a new alternative to start a driver ?

The common code is in src/display/devices/lib (5.0/5.3) or
display/drivers/lib (5.7). The closest thing to a generic driver is
the PNG driver, which essentially renders to a block of memory which
is then written out as a PNG file when the driver terminates.

> I would like to try to write a driver that would be a gtk widget and
> use it in gtkGRASS. Does it make sense ?

The closest existing driver would be XDRIVER.

Note that you can force XDRIVER to use an existing X window by setting
the environment variable XDRIVER_WINDOW to the window's XID. However,
it does require almost exclusive use of the window which it is given;
in particular, the creator must not attempt to redraw the window or
change its background pixmap. Also, if the creator selects ButtonPress
events, the mouse handling functions (Get_location_with_*) won't work
(although you may prefer to have the application handle that
directly).

Personally, I would consider making gtkGRASS render PNG images using
PNGdriver, and have the application just display those images. That
would allow layers to be hidden/shown instantaneously, and
individually redrawn, rather than having to redraw the entire stack
every time that something changes. It would also allow you to have
translucent layers (using e.g. gdk_pixbuf_composite()), which can't
readily be implemented with the existing display architecture.

More generally, the existing display architecture is long past its
prime; it was originally designed in the era of graphics terminals
like the Tek 4105, and it shows. If you're planning on writing a real
GUI for GRASS (as opposed to a hack like tcltkgrass or d.dm), you
would be better of avoiding the existing display architecture, IMHO. 
Not only is it extremely limited, but it isn't particularly efficient
either.

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