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