document-undo.cpp revision bd26ad566b0fe8a2d02fdf42fc4d5c2ea8c3ee93
/*
*
* Authors:
* Lauris Kaplinski <lauris@kaplinski.com>
* MenTaLguY <mental@rydia.net>
* Abhishek Sharma
*
* Copyright (C) 2007 MenTaLguY <mental@rydia.net>
* 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:
*
* \verbatim
void sp_document_done( SPDocument *document );
void sp_document_maybe_done( SPDocument *document, const unsigned char *key ) \endverbatim
*
* 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)
*/
#include <string>
#include <cstring>
#include "document-private.h"
#include "inkscape.h"
#include "document-undo.h"
#include "debug/event-tracker.h"
#include "debug/simple-event.h"
#include "debug/timestamp.h"
#include "event.h"
/*
* Undo & redo
*/
{
return;
if (sensitive) {
} else {
);
}
}
/*TODO: Throughout the inkscape code tree set/get_undo_sensitive are used for
* as is shown above. Perhaps it makes sense to create new functions,
* undo_ignore, and undo_recall to replace the start and end parts of the above.
* The main complexity with this is that they have to nest, so you have to store
* the saved bools in a stack. Perhaps this is why the above solution is better.
*/
}
void Inkscape::DocumentUndo::done(SPDocument *doc, const unsigned int event_type, Glib::ustring const &event_description)
{
}
{
}
namespace {
class CommitEvent : public InteractionEvent {
public:
{
if (verb) {
}
if (key) {
}
}
};
}
void Inkscape::DocumentUndo::maybeDone(SPDocument *doc, const gchar *key, const unsigned int event_type,
{
g_warning("Blank undo key specified.");
}
doc->collectOrphans();
doc->ensureUpToDate();
Inkscape::XML::Event *log = sp_repr_coalesce_log (doc->priv->partial, sp_repr_commit_undoable (doc->rdoc));
if (!log) {
return;
}
} else {
}
if ( key ) {
} else {
}
}
{
}
}
g_warning ("Incomplete undo transaction:");
}
}
if (update_log != NULL) {
g_warning("Document was modified while being updated after undo operation");
//Coalesce the update changes with the last action performed by user
if (undo_stack_top) {
} else {
}
}
}
{
} else {
}
if (ret)
return ret;
}
{
} else {
}
if (ret)
return ret;
}
{
}
}
{
}
}
/*
Local Variables:
mode:c++
c-file-style:"stroustrup"
c-file-offsets:((innamespace . 0)(inline-open . 0)(case-label . +))
indent-tabs-mode:nil
fill-column:99
End:
*/
// vim: filetype=cpp:expandtab:shiftwidth=4:tabstop=8:softtabstop=4 :