Page MenuHome

moving objects to different layer changes frame number
Closed, InvalidPublicTO DO


When I move object to different layer with keyboard shortcut, current frame number changes to 1. Do as follows to reproduce the bug:

1. Load factory settings
2. Change frame by 10 for example (shift+up arrow, BTW why it is changed from just up arrow?)
3. Move object to layer 2 with M->2 and... when pressing 2, frame changes to 1. Strange.

Tested on Mac OS X and ubuntu. The bug is present on both.

Event Timeline

Bug confirmed on my Debian wheezy 64… Seems like a very nasty shortcuts mismatch, will try to have a look at it :/

It has to do with the undo system, and the problem seems to exist in both 2.59 and 2.60rc. If you do another operator like rotating the object in between, it doesn't happen. Changing frames will not do an undo push, and move to layer uses undo/redo to work, it's related to that somehow.

Brecht, it happens with any operator when changing it's properties. Probably, operator re-do system should ensure if global push was made..

Bwa, this is a monster! Well, at least, it made me work & understand deep inside operators & undo system…

So, as said above, it’s an undo issue. The problem is that undoable operators only store their result in undo stack, not their initial state. So, when you undo (one way or another, from classical ctrl-Z to operator redo), you do not come back to the state just before the operator was applied, but to the state just after the previous undoable operator was applied… I.e. erase all non-undoable operators applied in-between.

I see no ideal way to fix this. The simplest solution is to store an additional undo step, just before applying any undoable operator (the attached patch is a proposition for that, but would need a check by someone more skilled in ops internals than me, I’m not sure I covered all possible cases…). This solves the problem, but has a drawback: it doubles the needed undo memory!

One could imagine to add a sort of “dirty” undo flag somewhere (WM, perhaps? or curundo?), to try to avoid dummy “init state” when applying several undoable ops in range…

But to be honest, I wonder why frame change is not undoable? Especially as the “current frame clicking/scrolling” of anim editors *is* undoable!

Anyway, I think we can postpone that to after 2.60!

Regarding the current rationale behind the frame change operators and undo:

This just happens to be a sub case of the missing undo push.

We've got plenty of issues with undo stack and global undo. Better to solve them all at one by introducing re-thinked design of this system. Added to TODO (
Thanks for the report, but closing it now.

Sergey Sharybin (sergey) changed the task status from Unknown Status to Unknown Status.Oct 12 2011, 9:29 AM