bulia byak schrieb:
On Nov 13, 2007 11:11 AM, Maximilian Albert <Anhalter42@...173...> wrote:
into the same state as, say, the latest saved one. When using undo/redo, this can easily be tested by comparing the respective locations in the undo history (commit #16491 fixes the mentioned bug in this respect). But any ideas how to find out whether the document returned to a previously saved state by "bypassing" undo, i.e. via real modifications to the document?
My feeling is that such "bypassing" should be simply eliminated, or at least minimized. If something changes the document, it must be undoable. If it makes no sense to be undoable, it must not change the document. An exception to this rule are various fixup operations that fix SVG which is broken or incompatible in some ways; however, such fixup should be done either before the XML tree is built (i.e. during parsing), or only during save (i.e. by changing only the objects and not the repr tree, and letting the objects rewrite the tree as they usually do during save).
Sorry, I probably used the word "bypassing" incorrectly. What I meant were changes (done by the user, not by the program, so you can't eliminate them :)) that are certainly undoable - and are recorded by the undo history - but bring the document into a previously saved state although it is internally considered as "modified".
For example, consider an empty document in which you create some objects. Then you select all of them and press 'delete'. This effectively brings the document into the original clean state, but the undo history is non-empty. That's why you are asked for confirmation when you want to exit, although there is nothing to save. I was wondering if there is a way to detect such situations, for example by using MD5 hashes as suggested by Thomas Worthington.
Max