[GRASSGUI] wxgrass gui status: was [GRASS-dev] Vect_snap_lines (list of lines)

[Glynn Clements]

Michael Barton wrote:

> I'm now working on a profiling module and will subsequently go through the
> tedious work of adding the rest of the commands to the menu--unless someone
> finds a faster way to do this or takes pity and does it for me ;-).

Is there some reason why you can't just dump descmenu (from
gmmenu.tcl) in a suitable syntax?

> 2. wxPython replacement for the nice r.edit module that Glynn did.

Presumably you mean d.rast.edit?

> This
> could be done pretty easily if we had an r.cell.edit module. This
> hypothetical module would accept coordinate(s), cat value(s), and label
> value(s), and change the cell or cells at the coordinates. e.g.

d.rast.edit.tcl uses r.in.ascii + r.patch. I'm not sure what advantage
a separate module would have over that.

> 5. A new implementation of nviz functionality in the wxPython GUI
> environment. This doesn't need to be  direct port of the current stand-alone
> nviz module (which dates back a decade). It could well appear to users as an
> nviz toolbar (code structure already in place for different toolbars) which
> displays its 3D images on an existing canvas and makes use of existing tools
> for zooming, panning, and querying for example. This should involve some
> thought and planning.

I wouldn't suggest using an existing canvas.

In general, you can only use OpenGL on a "GL canvas" widget, and you
shouldn't make every canvas a GL canvas "just in case". Apart from
anything else, a GL canvas will typically require additional memory
(possibly dedicated video memory) for the back buffer and Z buffer.

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