One theory has it that only board item actions should be undoable. For instance, creating a footprint, moving it, changing its properties, doing likewise with a track, via, etc. Things that are saved in the file but are not board items are not undoable. For instance, no undo for setting a drill origin marker, changing design rules, layer settings, etc.
Another theory has it that pretty much everything which is saved should be undoable. It would include all those things mentioned above, but would not include things like scroll position, zoom setting, etc.
And finally there are some apps that allow undo of everything.
Let’s call these the BOARD_ITEM camp, the SAVED_IN_FILE camp, and the EVERYTHING camp.
In my opinion everything that is saved in the file needs to be undoable.
Everything else is a bonus.
I for example quite liked the blender feature where one can undo a selection action. It happens quite often that you missclick. Then it is quite hard to click the same thing again to unselect the wrongly selected thing again.
Not sure if things like scroll position and zoom would make sense. (There is the auto zoom functionality so one will always find back “home”)
Hey Jeff, thanks for the patch to my bug report on the undo operation. It was nice to see that being addressed. I think you tend to approach this issue as a programmer (which you probably should). To you there is a clear delineation between those categories based on your knowledge of the inner workings of KiCad. To me as a user, things are not necessarily so black and white. I personally don’t care which layer of the software a certain action belongs to. To me it is a question of how practical it is. For example, this case of not being able to undo origin change always bugged me. When you move the board or a selection or create an array, you quite often have to change board origin. If you get it wrong, there was really no way to undo it easily without crawling with the cursor trying to get back to the previous state (which was not necessarily absolute origin in the first place) However I might not care as much for having undo for design rules or layer settings and other options, which don’t really affect my work flow.
I realize that from the point of view of implementing it, it may be all or nothing. In that case my vote would be:
+3 for SAVED_IN_FILE camp
I’d rather have more than less, even if it is something that I don’t use.