[GRASS-dev] Re: windows binaries

[Michael Barton]

This latter idea would work much better with interaction with the TclTk GIS
Manager. 

The GIS Manager expects for each d.* command to create a single PPM/PGM
pair, whose name is based on the PID obtained at the start of the procedure
for each GIS layer. These are then inserted into g.pnmcomp at the end of the
stack of GIS layers.

d.vect.thematic is treated like any other d.* command. If it did it's own
compositing via g.pnmcomp, it would still be complicated to get this into
the normal GIS layer stack of PPM/PGM pairs because it is not easy to pass
file names from a bash script to a TclTk script (this an the issue with
legend creation).

This approach might make other interesting effects possible.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


> From: Glynn Clements <glynn at gclements.plus.com>
> Date: Thu, 9 Nov 2006 22:19:32 +0000
> To: Michael Barton <michael.barton at asu.edu>
> Cc: Moritz Lennert <mlennert at club.worldonline.be>, Paul Kelly
> <paul-grass at stjohnspoint.co.uk>, Hamish <hamish_nospam at yahoo.com>,
> <grass-dev at grass.itc.it>
> Subject: Re: [GRASS-dev] Re: windows binaries
> 
> Here's an idea: if direct rendering had an option to initialise the
> framebuffer from an image file (or PPM/PGM pair), building up an image
> by having multiple d.* commands render on top of each other would
> work, in the same way that it does with persistent drivers.
>