Well, as a matter of principle SPXMLViewContent shouldn't have to know anything about desktops -- the calls to sp_desktop_done() should be happening in src/dialogs/xml-tree.cpp.
Not desktop, but document! Surely it must know its document - if it's editing this document. So what's the best way to figure out the document? Can we -> our way from a repr to its document? Or can we pass the SPDocument pointer in a data attached to the dialog or widget?
- Now that the text node changes are undoable, undoing editing a text
object in XML editor has the same problem as in this bug:
http://sourceforge.net/tracker/index.php?func=detail&aid=861462&grou...
That is, if you create a text node, switch to any other tool, and then reproduce this bug's sequence but using XML editor instead of F8, the
result
is the same. Which proves that the source of the problem is not text
tool,
but the wrong way text node changes are logged and undone by the repr logger. It was only obvious in text tool because no other tools
create/edit
text nodes. Can you please have a look into it?
Sourceforge is down again, so I can't get to the bug tracker. Could you please summarize the bug for me in more detail?
SF is up again. Baically the order of undo actions is wrong, and some actions may be lost, when text nodes are edited (no matter whether it's done by text tool or by XML editor).
-mental << signature.asc >>
_________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2f...
On Thu, 2004-02-05 at 12:05, bulia byak wrote:
Well, as a matter of principle SPXMLViewContent shouldn't have to know anything about desktops -- the calls to sp_desktop_done() should be happening in src/dialogs/xml-tree.cpp.
Not desktop, but document! Surely it must know its document - if it's editing this document. So what's the best way to figure out the document? Can we -> our way from a repr to its document? Or can we pass the SPDocument pointer in a data attached to the dialog or widget?
Er, I did mean document.
As a conscious design choice, SPXMLViewContent only needs to know one thing: the SPRepr it's attached to.
And yes, we will need to put a document pointer in there someplace -- the best way is as the data pointer given to g_signal_connect() (the callback function would be in document.cpp probably) connected to an SPXMLViewContent "changed" signal (which we will add).
SF is up again. Baically the order of undo actions is wrong, and some actions may be lost, when text nodes are edited (no matter whether it's done by text tool or by XML editor).
As I've already commented, the problem is that there is no unified undo layer for repr actions and other things (like text cursor movement).
The Repr transaction logging layer is fine as it is -- the thing is that we need undo records at the SPDocument layer that can hold more than just Repr transaction logs.
I do have a rough sketch in my mind for a new undo abstraction -- basically a generic undo stack and a 'log entry' base class that variuos subsystems can subclass for undoing/redoing specific things.
We could even use it for the next/prev zoom feature (i.e. use one of these generic undo stacks for document editing history, and another for zoom history).
-mental
participants (2)
-
bulia byak -
MenTaLguY