[GRASSGUI] wxgrass gui status: was [GRASS-dev] Vect_snap_lines
(list of lines)
glynn at gclements.plus.com
Fri May 11 15:58:24 EDT 2007
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?
> 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>
More information about the grass-gui