I have noticed that the bug affects only ellipses.
After Inkscape::DocumentUndo::undo reverted "d" attribute in svg:path and started new transaction, an idle handler is called. This handler calls SPDocument::_updateDocument. It results in execution of SPGenericEllipse::update_patheffect. The problem is that "d" attribute calculated here is different from original one and setting this ends up as uncommited change, later displayed as warning.
If SPGenericEllipse::update_patheffect and SPGenericEllipse::write set the same "d" attribute value, this bug would not appear. I'll write a post about this on mailing list.
Another possible solution to this bug is to call SPDocument::_updateDocument in Inkscape::DocumentUndo::undo before starting new transaction. That is what attached patch does.
Attached patch also secures the undo stack against other possible document changes introduced by _updateDocument.
I have noticed that the bug affects only ellipses.
After Inkscape: :DocumentUndo: :undo reverted "d" attribute in svg:path and started new transaction, an idle handler is called. This handler calls SPDocument: :_updateDocumen t. It results in execution of SPGenericEllips e::update_ patheffect. The problem is that "d" attribute calculated here is different from original one and setting this ends up as uncommited change, later displayed as warning.
If SPGenericEllips e::update_ patheffect and SPGenericEllips e::write set the same "d" attribute value, this bug would not appear. I'll write a post about this on mailing list.
Another possible solution to this bug is to call SPDocument: :_updateDocumen t in Inkscape: :DocumentUndo: :undo before starting new transaction. That is what attached patch does.
Attached patch also secures the undo stack against other possible document changes introduced by _updateDocument.