#83 Add 'undo' feature

[christian_et]

It just happened that I split a track in order to remove the last few trackpoints that were garbish. Accidentally I removed the good track instead of the garbish trackpoints. Realizing my mistake I immediately wanted to undo the last step. That was when I noticed Viking does NOT have an 'undo' feature!

Having such a feature, where I can undo and redo my last steps would really be helpful!
Without it, users have to repeat all steps since their last 'save' in case they accidentally delete the wrong thing.

Thanks in advance!

[Anonymous]

Yes, please - particularly with version 1.2 where mouse actions on the points can move them. You easily move points just by mistake now.

[Rob Norris]

I would if I could think of a way to implement this 'easily' - i.e. within time one allocates to doing Viking stuff.
ATM I can't even think of a way to begin this task :(

Stephan: True, however a couple of points
. You have choose the 'select' tool first - so it's not on by default.
. You have to click at the point twice to move it - the idea being to lessen the accidental movements
. I think in the next version I'll try to have a 'file modified' feature - which may help
. Just thought of an idea - ignore 'small' movement items when zoomed 'far out' - as one would never want to do this.
. Also could have escape key cancels current move operation

Of course these don't help after the fact - it's just a HARD problem as far as I can tell.

[christian_et]

Would it work to implement a list that keeps track of all (most) changes? And when the user presses "Undo" the last item from this list is simply undone! :)
Functions where an undo would be difficult or impossible to implement would simply need to clear this list (maybe warn the user first that this function cannot be undone)

[Anonymous]

Robbieonsea: About the accidental change - you're right that it needs several steps. But clicking on a point is often the easiest way to select a track that you want to look at. It's then quite easy to click on it again by mistake, or use the left mouse button when you actually wanted the right one. Or, for example, you want to see the elevation or the time of an individual point (which at the moment is only possible in the edit dialogue?).

Perhaps I'm really talking about two different features at the same time: an undo feature, but also better ways of viewing all information about individual points without getting dangerously near to editing them (e.g. one tool to select a point&track and then a different tool to move it).

[Guilhem BONNEFILLE]

I'm fully agree that "Undo" is a significant missing feature. But like Robbieonsea, I imagine such stuff need lot of time and I do not have time currently.

Neverthelees, anybody can help, providing in this ticket's thread as many as possible information about Undo design pattern and Glib/Gtk/gnome tips for implementation.

[Rob Norris]

Stephan: I plan to try to make the information of a trackpoint easier to see without the extra dialog.
Maybe put time/elevation/position into the status bar - although not much room ATM (the first status-bar field really takes up too much space) - ordering to put the position last as there's already the mouse position in the status bar.
And/or a tooltip effort when over the *selected* trackpoint.
It could be possible to do so for any trackpoint, but could be difficult to make this efficient (can the lookup *only* happen once the mouse has stopped moving? - would be nice if GTK API helps here - IIRC there is something??)

NB Generally is seems most people don't like modal editting (i.e. need to be in edit mode to change things), however without an undo it's a pain as one can accidentally change things in the 'view+edit all the time' mode :(

[Francewhoa]

+1 for a undo feature

I'm using 1.5 and there is no undo feature yet

[Pascal]

I would like to re-emphasize the need for "undo". Just to give another example: I wanted to join two routes, but they were joined "at the wrong end". Again, with an "undo" function this would be easy to revert.

[rooots]

I sincerely support this feature request.

r.

[christian_et]

I have recently implemented "Undo" for another project - I was amazed that it was much simpler than I expected, it didn't take me more than 4 hours!

Have a look at the Memento design pattern, here you can find a sample implementation: https://howtodoinjava.com/design-patterns/behavioral/memento-design-pattern/

[Rob Norris]

I have been thinking about this on and off for many years but there several difficulties:

Currently only limited method to align internal state with GUI view.
Normally it only tries to redraw what has changed, but an undo/redo could be anything and so more similar to loading a new (viking) file.

Memento design pattern can take lots of memory.
For instance my main Viking file is 250Mb big. So presumambly every change operation would save the entire memory state, and soon I'd run out of memory. Of course some size limits could prevent that and work for more common circumstances of a few tracks (rather than my couple thousand!).

A command design pattern seems more elegant, however this is probably even harder to retro fit into existing code rather than being built into the general program design at an early stage. It also suits OOP code better than C. A further complication is that memory (re)allocation can/will use different memory such that any pointers stored in a command will be invalid. One technique is to map from the old pointers to the new pointers as described here
https://www.drdobbs.com/an-efficient-undoredo-algorithm/184404861

I've often wondered how large programs such as GIMP, Inkscape, Blender, etc... work regarding Undo.
Unfortunately there doesn't seem to be any simple overview guides, and trying to understand the code takes much more time as often one needs to understand the various abstractions / internal workings of that program to get the overview (yet still be aware of any subtles/edge cases).

Of course with open source any one is welcome to have a go at it!

[Rodrigo Severo]

I agree that the command design pattern is the way to go: get each action available in Viking and convert it to a command.

I believe it would be possible to have perfectly working versions of Viking with parts of it's actions as commands and the rest as they are now.

If choosen carefully the first actions to be converted, there would be a usable and and useful undo feature way before everything being converted.