[GRASS5] Platform for next generation UI

Glynn Clements glynn at gclements.plus.com
Mon Jan 2 09:04:31 EST 2006


Michael Barton wrote:

> That is why it will be important to have support from the broader community
> and not just a 'UI development team'.
> 
> Is there anything that I and/or others (e.g., another person offered TclTk
> help) could do with TclTk (since we are already invested in it) to take some
> of the interim steps you mention while a more complete system is under
> development? I'm fooling around with vtcl and it seems to be not crashing
> now.

There's one specific task which springs to mind.

Here is a list of modules using the R_get_location_with_* functions:

display/d.barscale
display/d.geodesic
display/d.legend
display/d.measure
display/d.nviz
display/d.path
display/d.profile
display/d.rast.edit
display/d.rhumbline
display/d.text.freetype
display/d.what.rast
display/d.what.vect
display/d.where
display/d.zoom
imagery/i.ask
imagery/i.class
imagery/i.ortho.photo/photo.2image
imagery/i.ortho.photo/photo.2target
imagery/i.points
imagery/i.vpoints
lib/display
raster/r.digit
raster/r.le/r.le.setup
raster/r.profile
vector/v.digit

Figure out if any of them can be replaced or have the calls removed. 
Modules which are inherently interactive need to be replaced; cases
such as d.legend can simply have the "use mouse" feature removed
(ultimately, the GUI will handle placement and pass the position via
the at= option).

The existence of those functions is a major obstacle to re-working the
display libraries, because they need to handle not only display, but
also mouse input.

One possible approach: make d.m display maps in a Tk canvas widget
rather than using a monitor. Once that's done, simple mouse-driven
modules such as d.what.*, d.where, d.measure etc can be implemented as
part of d.m.

Implementing that isn't a vast amount of work.

1. Use the PNG driver (create another instance of it in etc/monitorcap
to prevent conflicts with other uses) to generate PPM/PGM files.

2. Use g.pnmcomp (the code needs to be copied from 5.3) to compose
multiple PPM/PGM layers into a single PPM file.

3. Use Tk's "image create photo ..." to read the PPM file, and
"$canvas create image ..." to add display it in the canvas widget.

Aside from cleaning up the display libraries the above has a couple of
benefits to the user:

1. Switching layers on and off only requires re-doing steps 2 and 3
above; you don't need to regenerate all of the images, which can be a
major performance gain (particularly if you have a lot of layers).

2. With a small amount of effort, you can support translucent layers
by running "pnmfunc -multiplier ..." on the alpha channels (PGM files)
to reduce their opacity.

-- 
Glynn Clements <glynn at gclements.plus.com>




More information about the grass-dev mailing list