[GRASS5] Platform for next generation UI

[Trevor Wiens]

On Mon, 2 Jan 2006 14:04:31 +0000
Glynn Clements <glynn at gclements.plus.com> wrote:

> 
> 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.
> 
Based on these comments and others in Glynn's reply to my query there
is a lot of interim work to do. This approach seems reasonable as it
moves things forward in a way we are assured of some result. I don't
know tcl/tk but am willing to learn and help or simply work on updating
documentation as things change if that would be more efficient. I'm
also willing to look through some of the modules and work with others
to set up alternative code based on compilation options or a runtime
setting to adjust module behaviour to operate in the current situation
or the planned one.

Perhaps others who have offered to help using specific tool kits Bob
with GTK and Christian with Qt can still work on conceptual issues such
as CLI/GUI interaction without committing us to any new toolkit yet,
but simply laying groundwork for a new GUI?

It is important to note however that improving the current Tcl/tk gui
increases our chances that we will not bother changing toolkits.

I hope my comments have been and will continue to be useful. I'm very
flexible on the approach we take. I was enthusiastic about building
something from scratch with Qt or GTK. Similarly, building with wxPython
or evolving the existing tcl/tk interface. Glynn's comments have been
wise and demonstrated a much better understanding of the situation
than I have, so I'm happy to defer to his and others judgement.

T
-- 
Trevor Wiens 
twiens at interbaun.com

The significant problems that we face cannot be solved at the same 
level of thinking we were at when we created them. 
(Albert Einstein)