This is one of the most annoying and visible recent bugs - right after clean start, the empty document is dirtied and it asks if I want to save it upon quitting. The undo stack is empty however. Can anyone please look into it? I think it's pretty recent.
bulia byak schrieb:
This is one of the most annoying and visible recent bugs - right after clean start, the empty document is dirtied and it asks if I want to save it upon quitting. The undo stack is empty however. Can anyone please look into it? I think it's pretty recent.
Bisecting the history (gee, I love git ...) revealed that this is caused by the grids code (the bug was introduced in rev #16332). The culpable function is sp_namedview_show_grids where sodipodi:modified is set to true when the desktop/namedview is set up. I added a quick fix that suppresses changes to sodipodi:modified upon startup. Johan, could you please have lock if everything still works as intended and it doesn't break anything else?
BTW, since changing the visibility of grids/guides modifies the xml tree, Inkscape asks if the document should be saved in such a case. In most situations this is presumably intended, but in some cases it's slighty inconvenient, for instance when grids are made visible and then invisible again so that the state of the document is effectively the same as before. This also applies to other situations, like when you create a couple of objects but then decide to delete them again - see bug #1824387. It's certainly not high priority, but I was wondering if there is an easy way to detect whether some changes brought the document 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? (Maybe it wouldn't be hard to implement a kind of checksum for the xml tree; but that's probably overkill).
Max
On Tue, 13 Nov 2007 15:11:04 -0000, Maximilian Albert <Anhalter42@...173...> wrote:
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? (Maybe it wouldn't be hard to implement a kind of checksum for the xml tree; but that's probably overkill).
Perhaps it seems overkill but wouldn't doing, say, an MD5 hash of the tree at file-open and another at file close (to decide if the "Save now" dialog is shown or not) simplify things overall? Nothing would ever need to be marked dirty and things like grid visibility/invisibility pairs would be handled for free.
Just a thought.
Thomas
Thomas Worthington schrieb:
On Tue, 13 Nov 2007 15:11:04 -0000, Maximilian Albert <Anhalter42@...173...> wrote:
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? (Maybe it wouldn't be hard to implement a kind of checksum for the xml tree; but that's probably overkill).
Perhaps it seems overkill but wouldn't doing, say, an MD5 hash of the tree at file-open and another at file close (to decide if the "Save now" dialog is shown or not) simplify things overall? Nothing would ever need to be marked dirty and things like grid visibility/invisibility pairs would be handled for free.
Yes, that's roughly what I had in mind. There may be situations, however, when you still want the document's states to be considered "equal" even if the xml tree was slightly modified. Say you create a rectangle, add a gradient and then delete the rectangle. This leaves the gradient definition in the defs but the document is "empty". I'm not familiar enough with artists' needs to decide whether it makes sense to store empty documents that only contain some additional gradient definitions (maybe as a template for later reuse?). But when such changes can be safely discarded upon exit it would be nice to be able to detect this somehow.
Max
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).
On Tue, 13 Nov 2007 11:57:29 -0400, "bulia byak" <buliabyak@...400...> wrote:
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.
Very strongly agreed; bypassing undo for some changes also creates problems in that it introduces discontinuities in the undo logs, which destroy many useful properties.
A few things for which undo is currently bypassed have no business being in the XML tree at all -- the most egregious example is sodipodi:modified.
-mental
MenTaLguY schrieb:
On Tue, 13 Nov 2007 11:57:29 -0400, "bulia byak" <buliabyak@...400...> wrote:
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.
Very strongly agreed; bypassing undo for some changes also creates problems in that it introduces discontinuities in the undo logs, which destroy many useful properties.
A few things for which undo is currently bypassed have no business being in the XML tree at all -- the most egregious example is sodipodi:modified.
So do people have a complete overview of what sodipodi:modified is needed for? Would it be very hard/tedious to eliminate? (I can imagine it would...) What other "things" are you referring to?
Max
On Tue, 13 Nov 2007 17:32:35 +0100, Maximilian Albert <Anhalter42@...173...> wrote:
So do people have a complete overview of what sodipodi:modified is needed for?
It's just a flag indicating whether the document has been modified since it was last saved. It could adequately be a C++ field in SPDocument, with a signal added for those things which want to track it.
Would it be very hard/tedious to eliminate? (I can imagine it would...)
Not hard. A little tedious, perhaps.
What other "things" are you referring to?
Just search the tree for the uses of sp_document_set_undo_sensitive.
The one that comes to mind most immediately is its use to elide id "fixups" for conflicting IDs from the undo record, though I reworked that code some time ago and might have been able to eliminate the elision (I forget offhand). That's probably the hardest one to fix if it's still in the tree; most of the rest were more trivial.
-mental
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
On Nov 13, 2007 12:13 PM, Maximilian Albert <Anhalter42@...173...> wrote:
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.
Well, that is possible - we even have an RFE for that I think - but it would be a very superficial nicety, costing a lot more trouble in implementing than it would bring benefits. Besides it would be fundamentally unreliable, because there are many aspects of XML that can be changed without actually changing the document, such as the order of attributes.
On Tue, 13 Nov 2007 16:20:56 -0000, bulia byak <buliabyak@...400...> wrote:
On Nov 13, 2007 12:13 PM, Maximilian Albert <Anhalter42@...173...> wrote:
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.
Well, that is possible - we even have an RFE for that I think - but it would be a very superficial nicety, costing a lot more trouble in implementing than it would bring benefits. Besides it would be fundamentally unreliable, because there are many aspects of XML that can be changed without actually changing the document, such as the order of attributes.
Is that really an issue? The bottom line is: "what is the functionality?". To me it is making sure that documents which have changed are prompted for saving, with not prompting for unchanged documents a secondary consideration (but a real consideration nonetheless). I would guess that opening a document, and having the attributes (or anything else) change *without any input from the user* would be relatively rare and restricted to when documents are imported from other apps or older versions of Inkscape, so I'd not be bothered (as a user) if I was prompted to save such docs even if I'd not done anything. Even this would probably be avoided most of the time if the initial hash was run after the tree was built and tidied up so only changes after that qualify as savable.
Having a hash system would surely *reduce* complexity by making the test for savability at a single point - when closing the document. No other module or programmer need ever worry about marking the document as dirty or subtleties of how undo works; the acid test is "has the tree changed?" and that can be definitively tested at a single point with no chance of a false negative (well, alright, 1 in 2**128 - much less than the chance of a programming error!). It seems to me, at first glance anyway, to be a better way to go about it than having a special flag which each new editing function must remember to poke.
TW
On Tue, 13 Nov 2007 16:55:18 -0000, "Thomas Worthington" <tww@...1737...> wrote:
Having a hash system would surely *reduce* complexity by making the test for savability at a single point - when closing the document. No other module or programmer need ever worry about marking the document as dirty or subtleties of how undo works; the acid test is "has the tree changed?" and that can be definitively tested at a single point with no chance of a false negative (well, alright, 1 in 2**128 - much less than the chance of a programming error!). It seems to me, at first glance anyway, to be a better way to go about it than having a special flag which each new editing function must remember to poke.
Using a hash is a not a bad idea in itself (it's how git works, for one example) but I don't think it's the best solution here.
I, too, find the idea of a special flag objectionable. But the undo list is directly pertinent to "has the tree changed?". If we want to eliminate the flag, the simplest thing to do is to check whether the current entry in the undo history was also current at the time the document was last saved. This is less expensive than computing a hash, and does not require establishing a particular normalized serialization of the document. It does require assigning unique ids to undo entires (and making sure that merging via _maybe_done results in a different id), but that's relatively trivial to implement.
-mental
On Nov 13, 2007 1:49 PM, MenTaLguY <mental@...3...> wrote:
I, too, find the idea of a special flag objectionable. But the undo list is directly pertinent to "has the tree changed?". If we want to eliminate the flag, the simplest thing to do is to check whether the current entry in the undo history was also current at the time the document was last saved. This is less expensive than computing a hash, and does not require establishing a particular normalized serialization of the document.
It also has another advantage: just one more check that the undo system is working properly and consistently at all time. The hash method might be considered if our undo was broken beyond repair and we wouldn't dare rely on it :)
On Tue, 13 Nov 2007 09:09:00 -0000, MenTaLguY <mental@...3...> wrote:
I, too, find the idea of a special flag objectionable. But the undo list is directly pertinent to "has the tree changed?". If we want to eliminate the flag, the simplest thing to do is to check whether the current entry in the undo history was also current at the time the document was last saved. This is less expensive than computing a hash, and does not require establishing a particular normalized serialization of the document.
Fair enough.
TW
participants (4)
-
bulia byak -
Maximilian Albert -
MenTaLguY -
Thomas Worthington