[GRASS-dev] [GRASS GIS] #2503: wxdigit: wrong undo & redo

[GRASS GIS]

#2503: wxdigit: wrong undo & redo
-------------------------+--------------------------------------------------
 Reporter:  mlennert     |       Owner:  grass-dev@…              
     Type:  defect       |      Status:  new                      
 Priority:  normal       |   Milestone:  7.0.0                    
Component:  wxGUI        |     Version:  svn-trunk                
 Keywords:  digitizer    |    Platform:  Unspecified              
      Cpu:  Unspecified  |  
-------------------------+--------------------------------------------------

Comment(by mlennert):

 Replying to [comment:5 mmetz]:
 > Replying to [comment:4 mlennert]:
 > > Replying to [comment:3 mmetz]:
 > > > Replying to [comment:2 mlennert]:
 > > > >
 > > > > There still is some confusion when one goes back one or two steps,
 then digitizes something else.
 > > >
 > > > The question is what should happen with the available redo steps if
 digitize something new after some undo steps. Eliminate the redo steps or
 insert the new changeset before the first redo step? This is handled by
 the wx digitizer, not the vector lib.
 > >
 > > I've tried three different programs (LibreOffice Writer, Inkscape and
 GIMP) and all discard these redo steps,i.e. when you do A, then B, then
 undo B, then do C, you cannot find B again.
 > >
 > > This seems to be the most intuitive behaviour to me.
 >
 > OK.
 > >
 > > >
 > > > > When you then undo and redo again, the stack seems to be mixed
 between the different paths, sometimes leading to objects left on screen
 even when going all the way back to the last possible undo.
 > > >
 > > > It seems that a new changeset is appended after the last redo step
 if available, leading to a mix-up.
 > > >
 > >
 > > Yes.
 >
 > Fixed in trunk r63341, please test.

 Much better !

 There is still one issue I've come upon: when features are automatically
 modified from the form they are digitized in because of overlaps, the
 second original feature causing the overlap seems to be erased from the
 undo stack, meaning that it remains, even if you undo all the way to
 origin or if you close without saving.

 To reproduce, digitize a line and then a second line that crosses that
 line. The lines are correctly split at the intersection. If you then undo
 the second line remains in its original (unsplit) form. The same is true
 for two overlapping polygons or a line crossing a polygon.

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/2503#comment:6>
GRASS GIS <http://grass.osgeo.org>