|static void||finish_incomplete_transaction (SPDocument &doc)|
|void||sp_document_cancel (SPDocument *doc)|
|void||sp_document_clear_redo (SPDocument *doc)|
|void||sp_document_clear_undo (SPDocument *doc)|
|void||sp_document_done (SPDocument *doc, const unsigned int event_type, Glib::ustring event_description)|
|bool||sp_document_get_undo_sensitive (SPDocument const *document)|
|void||sp_document_maybe_done (SPDocument *doc, const gchar *key, const unsigned int event_type, Glib::ustring event_description)|
|gboolean||sp_document_redo (SPDocument *doc)|
|void||sp_document_reset_key (Inkscape::Application *, SPDesktop *, GtkObject *base)|
|void||sp_document_set_undo_sensitive (SPDocument *doc, bool sensitive)|
|gboolean||sp_document_undo (SPDocument *doc)|
Undo/Redo stack implementation
Copyright (C) 2007 MenTaLguY <email@example.com> Copyright (C) 1999-2003 authors Copyright (C) 2001-2002 Ximian, Inc.
Released under GNU GPL, read the file 'COPYING' for more information
Using the split document model gives sodipodi a very simple and clean undo implementation. Whenever mutation occurs in the XML tree, SPObject invokes one of the five corresponding handlers of its container document. This writes down a generic description of the given action, and appends it to the recent action list, kept by the document. There will be as many action records as there are mutation events, which are all kept and processed together in the undo stack. Two methods exist to indicate that the given action is completed:
void sp_document_done (SPDocument *document); void sp_document_maybe_done (SPDocument *document, const unsigned char *key)
Both move the recent action list into the undo stack and clear the list afterwards. While the first method does an unconditional push, the second one first checks the key of the most recent stack entry. If the keys are identical, the current action list is appended to the existing stack entry, instead of pushing it onto its own. This behaviour can be used to collect multi-step actions (like winding the Gtk spinbutton) from the UI into a single undoable step.
For controls implemented by Sodipodi itself, implementing undo as a single step is usually done in a more efficent way. Most controls have the abstract model of grab, drag, release, and change user action. During the grab phase, all modifications are done to the SPObject directly - i.e. they do not change XML tree, and thus do not generate undo actions either. Only at the release phase (normally associated with releasing the mousebutton), changes are written back to the XML tree, thus generating only a single set of undo actions. (Lauris Kaplinski)
Definition in file document-undo.cpp.