Inkscape undo system
Can anyone point me to some code that would serve as a nice illustration of how the Inkscape undo system works? I've been reading the Session and SimpleSession classes and the way they are used in the functions in document-undo.cpp; is that a good place to begin, or are there better starting points?
In particular, I'm wondering what the best way to clear the undo and redo stacks is, as it's crucial to the correct functioning of Inkboard. When a user synchronizes his or her document with another user or with a chatroom, that synchronized state must become the new original state of the user's document. sp_document_clear_undo and sp_document_clear_redo, from their code, seem to be what I want, but I can't quite figure out how to use them to attain the desired effect.
-- David
Quoting David Yip <yipdw@...635...>:
sp_document_clear_undo and sp_document_clear_redo, from their code, seem to be what I want, but I can't quite figure out how to use them to attain the desired effect.
Could you elaborate on the difficulties you are experiencing?
-mental
On Tuesday 02 August 2005 04:13 pm, mental@...3... wrote:
Could you elaborate on the difficulties you are experiencing?
-mental
Sure thing -- I probably should have done that in the original message...
Client synchronization in Inkboard currently functions like this. Given two users A and B:
1. A sends a request response to B. 2. B receives the request response, clears all definitions, layers, and metadata, and sends a positive acknowledgement to A. 3. A receives the acknowledgment from B, sends a DOCUMENT_BEGIN signal to B, and begins to send the document. 4. After A has sent the entire document to B, A sends a DOCUMENT_END signal. 5. After B processes the DOCUMENT_BEGIN signal, B begins processing incoming messages and applying the changes to the document tree. 5. After B processes DOCUMENT_END, B clears its undo/redo stacks.
B does not process changes as it receives them: it queues up incoming messages and then processes messages periodically. An Inkboard client keeps track of the current sequence number for each client it knows about (via chatroom or user-to-user conference), and will refuse to process messages that appear to arrive late (i.e. have a sequence number smaller than the latest one processed). This will result in problems with m
The calls to sp_document_clear_undo and sp_document_clear_redo in step (5) have been inserted at around line 125 of src/Jabber_whiteboard/message_processors.cpp.
If I'm understanding the undo/redo mechanism properly, this sequence of actions should result in the desired behavior: A and B with a synchronized document and B unable to revert to the pre-synchronization point. However, when I synchronize A and B and immediately run an undo operation on B, I can recover the point immediately after B cleared its document in step (2), which results in an unusable document.
-- David
participants (2)
-
unknown＠example.com -
David Yip