This MR is a first attempt at an undo-function.
This MR introduces an undo for trajectories only that is, changes to the settings are not undo'able. This is primarily for use during correction of trajectories. The implementation is quite simple: Each time the user changes the trajectories (using same counting mechanism as autosave), we save all current trajectories on a stack. When the user hits Ctrl+z, we put the current state of trajectories onto the redo-stack and replace the current trajectories with the newest trajectories from the undo-stack. Ctrl+shift+z does the same with the roles reversed.
This behaviour is significantly easier to implement than more sophisticated undo-behaviour. Some things to note about this:
- Only manual steps are recorded -> automatic things like tracking are only incidentally undone as well
- Might lead to measurably higher memory usage; currently a single TrackPoint takes 112 Bytes, and this might increase with #349
- Depends on the length of the video and number of visible people each frame; what would be acceptable?
- Does not care about changes on project settings, so no help during setup of pet-file
Especially with the first point, I'm not sure about the usability of the approach. On the one hand, I'd imagine stuff like retracking usually happens after e.g. deleting the future part of the trajectory. So the tracking can be undone by resetting to that manual intervention. On the other hand, I'm not sure if this is always the case. However, since this is simpler to implement and an improvement upon the current state either way, I think we should investigate the user experience on this implementation anyway.
the pre-build checks succeed
naming conventions are met (see .clang-tidy for detailed information)
no static analyzer warnings in new code parts (e.g., use clang-tidy for checking)
old versions of pet-files are still loadable
new elements are also saved and loaded from pet-file
check if tab order is still correct
all new SpinBoxes are promoted
new keybindings added to