Animator Poll - Frame Change Undo

This evening, the old issue of when (and if) frame changes should get their own entries in the Undo Stack. The key question is: Is the current approach in Blender good, or if not, what should be happening?


Now for some commentary on the matter.

Some terminology first:
- "undo push" = "an entry is added to Undo Stack"
- "Undo Stack" = what you see when you use Ctrl-Alt-Z
 
Each entry in the Undo Stack represents a snapshot of the current state of your scene+models/etc. (i.e. all the stuff in your Blender file at this point in time, but NOT including any View/Screen related stuff, such as screen layouts, editor settings, etc.). By "undoing" (Ctrl-Z), you're telling Blender to revert it's state back to the state it was in when that last snapshot was taken.

The current system in Blender:
1) Clicking or scrubbing to change frame in timeline results in an undo push
2.1) Typing arrow keys to step to other frames - one keypress = one framestep/jump - no undo pushes

2.2) Holding down arrow keys to keep moving forwards/backwards, effectively playing back the timeline - no undo pushes

3) Using number buttons (e.g. current frame button on timeline header) to change frame - undo push

Why does it work this way?
The current system is really an attempt to balance:
a) the need to have frequent-enough undo pushes, for times when we think that you as an animator "intended" to change frame to start setting a new pose on that frame, vs
b) not having enough undo pushes, resulting in cases where undoing a pose suddenly jumps you back to a completely unrelated frame (perhaps right back to the start frame or worse), meaning that you need try to remember what frame you were working on to recover that timing 
c) not flooding the undo stack with just frame-changed undo states everytime for example you start jumping between frames (or perhaps scrubbing?) checking on the pose change between those frames

Hence, the following assumptions were made. See how these map the two sets of points:
- To chose a frame to frame to start posing on, an animator will likely just click somewhere in the Timeline (1+a), then start posing the character.
- If there wasn't an undo push here, you may end posing a rig, undoing all the way, end up going over the invisible frame-jump (not registered as a separate undo state) and start keying your pose again on the wrong frame (1+b). [Side note: I've run into this myself a few times - posing on the wrong frame, only to notice quite a bit of work later]
- While scrubbing may result in the animator ending up on a frame different from the one they were originally on, or perhaps just end up on the same one again, this is ultimately just handled by the same operator as the timeline click. Hence, all the time scrubbing will ultimately just equate to a single undo push representing the endpoint of the scrub (1+c). If you aren't happy with where you end up after a scrub, it's just an undo push away.
- Editing number buttons automatically adds an undo push when the editing is done. Since you're entering a frame in directly, you most probably know what you're doing (i.e. you "intend" to do that). (3+a)
- A common technique for previewing motion without perhaps constantly bearing down on your mouse/tablet/pointing-member (whatever that may be) is to "single step" (left/right arrow, +1/-1 frame at a time) or "flip between" (jump between keyframes) repeatedly until you get a good feel of what you're doing. If each of these was a separate undo push, you'd soon end up with hundreds of irrelevant undo pushes from all that undo action (2.1 + c)
- Perhaps you find the playback too slow? Then try holding down an arrow key to get apparently "faster" playback (or at least it seems that way sometimes). Now, what you might not know is that doing that just ends up running the same operator as for single-stepping (2.1) everytime Blender detects that you've still got that arrowkey held. If we registered each one of those times that said operator runs, then we'd quickly get hundreds of irrelevant undo pushes too (2.2 + c)

How does everyone else do it?
Well, an unconfirmed source claimed that Maya just creates undo pushes regardless for each one of these actions. And apparently for that reason, that is one of the little banes of animator existence there.

As for anything else, I wouldn't have a clue (and probably wouldn't be legally allowed to do so to just "check them out" for the purpose of developing Blender ;)

Some other alternatives to what we've got now:
1) Patch up the other frame change operators so that they run as modal operators, which keep running until they key that calls them is released. Then we get single undo pushes for each of those sessions (though perhaps still not for the flip-flopping)
2) Something similar to the above, but integrated lower down (as part of operator functionality)
3) Go back to a state where we don't have any undo pushes for frame changes anywhere, while risking the problems of "b" (judging from the number of bugreports I often field on a number of other things like this, I'd safely expect a number of recurring reports, perhaps just clustered after releases though, on this very matter)

Alright, that's enough from me about this matter? Let's hear what the animators say!