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

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

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

On 5/11/07 8:30 AM, "Martin Landa" <[hidden email]> wrote:

> 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: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton 

_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]>

_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui
Reply | Threaded
Open this post in threaded view
|

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

Michael Barton

On 5/11/07 12:58 PM, "Glynn Clements" <[hidden email]> 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


_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui
Reply | Threaded
Open this post in threaded view
|

Re: 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?
>
> 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.

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

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

No.

> If it is just pure TclTk with pure GRASS commands,

It is.

--
Glynn Clements <[hidden email]>

_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui
Reply | Threaded
Open this post in threaded view
|

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

Daniel Calvelo
On 5/12/07, Glynn Clements <[hidden email]> wrote:
[on dumping tcl's menu structure to python]
> > 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.

--
-- Daniel Calvelo Aros

_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui
Reply | Threaded
Open this post in threaded view
|

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

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


On 5/12/07 11:30 AM, "Daniel Calvelo" <[hidden email]> wrote:

> On 5/12/07, Glynn Clements <[hidden email]> wrote:
> [on dumping tcl's menu structure to python]
>>> 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: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui
Reply | Threaded
Open this post in threaded view
|

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

Michael Barton
In reply to this post by Glynn Clements

On 5/12/07 4:29 AM, "Glynn Clements" <[hidden email]> wrote:

>
> 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: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


_______________________________________________
grassgui mailing list
[hidden email]
http://grass.itc.it/mailman/listinfo/grassgui