this one looks like an urgent backport candidate for me?
I think that one of my doctorate students just complained to me
that digitizing failed for him (I need to ask).
In any case, this should go then into relbranch64 before it is
forgotten (and it is also more relevnt than the other r.li cleanup
fixes done in dev6branch.
What do you think?
Markus
---------- Forwarded message ----------
From: <svn_grass@osgeo.org>
Date: Sat, Jun 15, 2013 at 8:56 AM
Subject: [GRASS-SVN] r56709 -
grass/branches/develbranch_6/raster/r.li/r.li.setup
To: grass-commit@lists.osgeo.org
Author: hamish
Date: 2013-06-14 23:56:25 -0700 (Fri, 14 Jun 2013)
New Revision: 56709
Modified:
grass/branches/develbranch_6/raster/r.li/r.li.setup/circle.txt
grass/branches/develbranch_6/raster/r.li/r.li.setup/polygon.txt
Log:
eXit r.digit with save, not Quit without saving
this one looks like an urgent backport candidate for me?
I think that one of my doctorate students just complained to
me that digitizing failed for him (I need to ask).
In any case, this should go then into relbranch64 before it
is forgotten (and it is also more relevnt than the other r.li
cleanup fixes done in dev6branch.
What do you think?
Hi Markus,
that was just a first commit of a bigger r.li cleanup which I have
started locally but not yet committed to the dev branches. I wanted
to commit those various small fixes now to get them out of the way
since my 'svn diff' was getting a bit cluttered. I am not surprised
things failed really, to work well it will still need some commits I
haven't made yet (I am just working through the code so far: completely
untested), e.g. for that r.digit call related to the circle.txt file
in the commit it will need the output map name passed on the command
line since I changed r.digit into a "normal" G_parser() module 7+ years
ago.
For grass7 there is Luca's g.gui.rlisetup.py (I am not totally
convinced about the g.gui.* naming), I am just keeping the raster/r.li
r.li.setup dir in sync to avoid older code being in the "newer"
branches. Much of r.li.setup will be deleted in trunk eventually since
it needs Xmons, tcl/tk, shell scripts, etc. and is replaced by the
wxPy version.
So I think r.li.setup is too much broken to worry about for 6.4.3; I
look to make one fix and see three more. Let's get 6.4.3 out the door
asap and keep an improved r.li as a goal for 6.4.4. I looked at the
list of r.li bugs in the trac system earlier, it is in need of some
care. AFAICT it's nothing fatal, just many small fixes to work through.
On 15 June 2013 12:09, Hamish <hamish_b@yahoo.com> wrote:
Hi Markus,
Hi Hamish
For grass7 there is Luca's g.gui.rlisetup.py (I am not totally
convinced about the g.gui.* naming), I am just keeping the raster/r.li
r.li.setup dir in sync to avoid older code being in the "newer"
branches. Much of r.li.setup will be deleted in trunk eventually since
it needs Xmons, tcl/tk, shell scripts, etc. and is replaced by the
wxPy version.
Hi think that r.li.setup could be removed from grass7.
For the name I think it is more consistent with the other grass7 GUI modules