-
Dmitry Kazakov authored
https://bugs.kde.org/show_bug.cgi?id=293314 He-he ;) It happened due to the following: 1) Undo of removeLayer command added a layer and issued setDirty for this node 2) The scheduler calculated the walker for this update and put it into the queue 3) Undo of addLayer command removed one of the layers of the stack, leaving the queued walker in a very interesting state. The point is that the walker stored a shared pointer to the removed node, so it still had access to it and there were no crashes, but its behavior was not obvious (read "unpredictable"). So I extended the meaning of the walker's checksum. Now it depends on the graph sequence number as well, so the walker is recalculated when he gets to know its data is outdated. About Graph Sequence Number. Now KisNodeGraphListener maintains an integer which shows current "version" of the graph or its "sequence number". This integer is incremented on every change made to the graph. So if you have some information about the graph which was acquired while the sequence number was X and now you see the number equals to Y, you should know your information is outdated and someone has changed the graph since then. BUG:293314
5ea31706