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

[Michael Barton]

This is a good place to give a quick update and lookahead for the
development gui. Jachym, Martin, Daniel, and others have done a real bang up
job of collaborating to get this new interface up and running so fast. It's
been a really big job.

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 ;-). This
should happen soon--within the next month probably.

This will bring wxgrass pretty much up to serious testing/production status.
In order to completely transition from TclTk to wxPython, we will need the
following:

1. wxPython replacement for v.digit. As indicated below, Martin is working
on this.

2. wxPython replacement for the nice r.edit module that Glynn did. 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.

r.edit.cell map=[raster map] coords=[x,y] cat=[new catnum] label=[new label]
There would be some advantage of allowing batch changing of multiple cells,
but this is not essential if it is too complicated (e.g.,
coords=[x1,y1,x2,y2,...] cat=[cat1,cat2,...] label=[label1,label2,...]

I can immagine r.edit.cell being be used in a variety of other script
applications too, especially dynamic modeling.

3. A non-interactive version of g.setproj OR a further expansion of g.proj
to allow it to use the same kind of input data on projections, datums, etc
from the lists that GRASS provides. We've got an almost functional
location-setting wizard that is really nice. But we're stuck on not being
able to replicate the functionality of g.setproj with currently available
tools.

4. A wxPython replacement for the georectify module. I will start working on
that after the profile module.

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 think that we are quite close on all but #5. I don't know what #5 would
entail but think that it requires expertise that I at least don't
have--although I am willing to help however I can and I'm sure that the rest
of the team feels the same.


Michael

Hi all,
working on v.edit I need snapping fn which does not operate globally
but only on the list of selected lines. I modified snap.c, added
Vect_snap_lines_list(), current Vect_snap_lines () calls
Vect_snap_lines_list(). Behaviour of Vect_snap_lines () fn should be
untouched.
Any objections to commit these changes?
Martin

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

phone: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton

[Glynn Clements]

Post by Michael Barton
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?

Post by Michael Barton
2. wxPython replacement for the nice r.edit module that Glynn did.

Presumably you mean d.rast.edit?

Post by Michael Barton
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.

Post by Michael Barton
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.

[Michael Barton]

Post by Glynn Clements

Post by Michael Barton
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.

Post by Glynn Clements

Post by Michael Barton
2. wxPython replacement for the nice r.edit module that Glynn did.

Presumably you mean d.rast.edit?

Yes

Post by Glynn Clements

Post by Michael Barton
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.

Post by Glynn Clements

Post by Michael Barton
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: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton

[Glynn Clements]

Post by Michael Barton

Post by Glynn Clements

Post by Michael Barton
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.

Tcl would be far more appropriate, as the menu is already in Tcl
syntax.

Post by Michael Barton
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.

Can you give an example of the required Python syntax?

Post by Michael Barton

Post by Glynn Clements

Post by Michael Barton
2. wxPython replacement for the nice r.edit module that Glynn did.

Presumably you mean d.rast.edit?

Yes

Post by Glynn Clements

Post by Michael Barton
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.

No.

Post by Michael Barton
If it is just pure TclTk with pure GRASS commands,

It is.

[Daniel Calvelo]

On 5/12/07, Glynn Clements <***@gclements.plus.com> wrote:
[on dumping tcl's menu structure to python]

Post by Glynn Clements

Post by Michael Barton
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.

Can you give an example of the required Python syntax?

It's in gui_modules/menudata.py and is modelled after gmmenu.tcl. It's
just 4-tuples of strings (label, description, python command called,
grass module), where all four empty means a separator. These are
arranged in a tree (of tuples, but arrays would do) corresponding to
the menu structure, as pairs of ("menu entry",child) with child being
either a 4-tuple of entries or another pair.

The only tricky part is in those commands that require internal work
by tcl (mostly the first menu item); the rest are mainly
correspondences between menu items and grass commands.

I'd do that using a simple protocol (coding the python- ot
tcl-specific parts as special codes) to access a configuration file in
JSON, XML or tab-indented specifications. Not much time to do that
right now, though.

Daniel.

[Michael Barton]

Below is an example from the first part of the file. It is modeled on menu
structures from the wxPython book. The indents don't matter; they are only
to make it easier to work with.

Michael

Post by Daniel Calvelo
[on dumping tcl's menu structure to python]

Post by Glynn Clements

Post by Michael Barton
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.

Can you give an example of the required Python syntax?

It's in gui_modules/menudata.py and is modelled after gmmenu.tcl. It's
just 4-tuples of strings (label, description, python command called,
grass module), where all four empty means a separator. These are
arranged in a tree (of tuples, but arrays would do) corresponding to
the menu structure, as pairs of ("menu entry",child) with child being
either a 4-tuple of entries or another pair.
The only tricky part is in those commands that require internal work
by tcl (mostly the first menu item); the rest are mainly
correspondences between menu items and grass commands.
I'd do that using a simple protocol (coding the python- ot
tcl-specific parts as special codes) to access a configuration file in
JSON, XML or tab-indented specifications. Not much time to do that
right now, though.
Daniel.

return [(
("Files", (
("Import", "Import files", "self.runMenuCmd", "r.in.gdal"),
("Export", "Export files", "self.runMenuCmd", "r.out.gdal"),
("","","", ""),
("E&xit", "Exit from wxgui.py", "self.onCloseWindow", "")
)),
("Config", (
("Region", "Set region", "self.runMenuCmd", "g.region"),
("","","", ""),
("Set display font", "Set default font for GRASS displays",
"self.DefaultFont", ""),
)),
("Raster", (
("Develop map", (
("Digitize raster", "Digitize raster",
"self.runMenuCmd", "r.digit"),
("","","", ""),
("Compress/decompress raster file", "Compress/decompress
raster file", "self.runMenuCmd", "r.compress"),
("Manage boundary definition (WHICH COMMAND?)", "Manage
boundary definition", "self.runMenuCmd", "r.region"),
("Manage null values", "Manage null values",
"self.runMenuCmd", "r.null"),
("Manage timestamp for files", "Manage timestamp for
files", "self.runMenuCmd", "r.timestamp"),
("Quantization for floating-point maps", "Quantization
for floating-point maps", "self.runMenuCmd", "r.quant"),
("Resample (change resolution) using nearest neighbor
method", "Resample (change resolution) using nearest neighbor method",
"self.runMenuCmd", "r.resample"),
("Resample (change resolution) using regularized spline
tension", "Resample (change resolution) using regularized spline tension",
"self.runMenuCmd", "r.resamp.rst"),
("Support file creation and maintenance", "Support file
creation and maintenance", "self.runMenuCmd", "r.support.sh"),
("","","", ""),
("Reproject raster from other location", "Reproject
raster from other location", "self.runMenuCmd", "r.proj"),
("Generate tiling for other projection", "Generate
tiling for other projection", "self.runMenuCmd", "r.tileset"),
)),


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

phone: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton

[Michael Barton]

Post by Glynn Clements
Tcl would be far more appropriate, as the menu is already in Tcl
syntax.

Done.

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

phone: [phone]
fax: [phone]
www: http://www.public.asu.edu/~cmbarton