I'm working on a developer application (an editor) based on Qt 4.5
Beta. Sorry for the longish email:
When the editor is just a simple QTextEdit, it's pretty easy to just
rely on the built-in Undo functionality (bound to Ctrl+Z) of the
QTextEdit. However, once we introduce other ways of editing the
document, it really becomes necessary to have a 'document-level' Undo
that includes things beyond typing events. For example, my editor is
for DOM-based documents, and I now have a DOM Browser tree control.
If I want to add the ability to remove a node by right-clicking on a
node in the DOM browser, I need to be able to undo that action in the
proper sequence. The use case is as follows:
- user types in a new value of an attribute in the text editor
- user removes a node by right-clicking it in the the DOM browser
- user manually adds a new node by typing in the text editor
The undo stack should look something like:
Undo Typing
Undo Delete Node
Undo Typing
My options here seem to come down to two main ones:
a) Reduce all editor actions down to text changes in the source
document and then route all Undo requests to the QTextEdit (which by
default tracks all edit actions in its internal Undo stack).
Ultimately all edits to the document come down to changes in the
document's text anyway, so there is some rationale for this approach.
Initially it's probably the easiest approach, but t can be an
expensive operation (performance-wise), since the DOM Browser acts on
the DOM nodes (QDomNode, etc) and then re-serializes the entire
QDomDocument to keep the text editor in sync, it means the entire
QTextEdit's contents have been replaced so the internal Undo commands
will get rather large the more non-typing actions the user does. I'd
really like to see things go the other way (Undo commands for
non-typing actions become smaller).
b) Prevent the QTextEdit's internal Undo functionality
(setUndoRedoEnabled(false)) and then manage all text changes as
subclasses of QUndoCommands in a document-level QUndoStack. This is
the approach I was going to try. For non-typing actions we record the
relevant details (the QDomNode removed, for instance). For typing
chagned it means we have to capture any changes to the QTextEdit text
contents caused by the user and create InsertTextCommand,
DeleteTextCommand, etc. The question I have is: how to differentiate
a change to the QTextEdit contents originated from the user (via
typing or pasting or cutting) or if it came from an 'undone' command.
For instance:
- user types in "J" in the document - this is caught by a slot
receiving the QTextEdit's contentsChanged() signal). The action is
saved on the QUndoStack as a InsertTextCommand (has a reference to the
QTextEdit, the position and the string "J")
- user clicks "Undo" - the InsertTextCommand is undone and "J" is
removed from the QTextEdit. However, this causes the
contentsChanged() signal to be emitted again (which would create a
DeleteTextCommand, etc).
How to prevent this recursion?
_______________________________________________
Qt4-preview-feedback mailing list
[email protected]
http://lists.trolltech.com/mailman/listinfo/qt4-preview-feedback
