This appears to me like an 'evil hack' ( which is how I rarely annotate my code to workaround things ;) ) - and such a hack should not be the basis of a whole undo framework.
What happens with your internal queue if the user flushes undo ? ( alternatively maya flushes it when creating a reference, or when unloading it, or removing it ). To me it appears the index on the garbage node would stay as it was, as well as your internal queue. Perhaps you can register a callback that will always be triggered in such cases, so you can react to it. When the user changes scenes, you will loose your previous garbage node, and have to create a new one. Perhaps you could set the node shared, or add yet more callbacks, to be notified in such cases. Just to get this node work right one has to do whole lots of work and catch many special cases - all this could possibly break in yet another unforseen situation. What happens if I trigger one undoable pymel API command, that internally calls 10 more undoable commands ( and we could go on like it ). The user should be able to undo it with just one undo step, but your node got changed 11 times in the meanwhile, causing 11 operations to be put onto the undo stack. To fully undo, you would have to undo all 11 changes. Even if it would not fill up maya's undo queue, it would be impossible to actually undo the right thing ( rendering the whole undo system unusable ). What do you think about the flagged issues ? --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/python_inside_maya -~----------~----~----~----~------~----~------~--~---
