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

[Michael Barton]

On 5/11/07 12:58 PM, "Glynn Clements" <glynn at gclements.plus.com> wrote:

> 
> 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?

I wish. Probably an awk and regedit wizard could craft a script to do this
automatically. But sadly, I would be able to cut and past the commands in
less time than it would take me to figure out such a script.

> 
>> 2. wxPython replacement for the nice r.edit module that Glynn did.
> 
> Presumably you mean d.rast.edit?

Yes

> 
>> 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.

I thought d.rast.edit was a combined C/TclTk application like v.digit. If it
is just pure TclTk with pure GRASS commands, then it can be redone in
wxPython. At the speed of single cell edits by a user, r.in.ascii + r.patch
is probably just fine. If scripted for iterated multicell updates, I suspect
a C module would be considerably more efficient.

> 
>> 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.

Sorry. I wasn't clear. Slipping into TclTk thinking. I meant that we might
be able to put a GL Canvas into the same frame where a 2D canvas (i.e.,
bufferedpaintDC) shows a map. I was thinking of having "nviz" pop up a new
toolbox and replace the bufferedpaintDC with a GL canvas. This avoids
opening a completely new window on the screen. But there may be other,
better ways to do this.

Michael

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

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