--===============1358865950==
Content-Type: multipart/alternative;
boundary="Boundary-00=_2ouMJf7ihDKh7I6"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
--Boundary-00=_2ouMJf7ihDKh7I6
Content-Type: text/plain;
charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
On Sunday 30 November 2008 09:01:31 Pierre Stirnweiss wrote:
>
> This is what I propose:
> - keeping the idea of "macro command" which parents any subsequent "undo
> command" created after undoCommandAdded signal, I would like to avoid
> having "opened command" at the end of a user action. This is as far as I
> have seen so far only the case for text keying. I think we could use the
> merging facility in that case. That would make things clearer. I will try
> an implementation, and commit if it compiles/work with correct behavior.
>
> - then, I would like to group everything that is related to a user action
> in one place. For example, I don't see why a new paragraph action (this is
> just one example, I am pretty sure there are others) is half made in the
> TextSelectionHandler and in the TextTool. This is confusing and a hell to
> debug.
>
I have committed a working version of the above. To summarize what I have
done:
- the text tool public interface has not been changed.
- in the private part, the following was done:
i. declare an enum of editing actions. this is used for the merging test
(for implementing QUndoCommand::id()
ii. transfer the declaration of UndoTextCommand from the addUndoCommand
method to the header, the implementation is in the cpp file. This is to make it
accessible from friend classes
- I have created two "commands" derived from QUndoCommand in the command
subdir: the TextInsertTextCommand and the TextInsertParagraphCommand. both are
declared friend of the TextTool.
These commands explicitly set themselves as the m_currentCommand in the
TextTool at the begining of their cstr and set back the m_currentCommand to 0
at the end. In between, all the changes to the document are done (minus the
removal of inlineObjects, which I have not yet looked into, still TODO).
That way all the undoCommandAdded will create a UndoTextCommand parented on
the current command. When the command is finished, the currentCommand pointer
is reset so no further commands are getting eaten up.
The TextInsertTextCommand checks whether it can merge with a previous one. If
so, the commands are merged, "transferring" the child UndoTextCommands to the
new common command.
The TextInsertParagraphCommand does not merge with the insertText. That
behavior was done on purpose (see previous post), but can easily be modified.
I think grouping all editing actions of a single user perspective action into
one single object is actually clearer and easier to maintain down the road.
It might also help with the call of Florian for making the undo/redo available
to other tool, I am not really sure what is exactly needed there but would be
glad to look into it also.
If this solution is acceptable for everybody, I have already most of the
editing actions ready.
Pierre
--Boundary-00=_2ouMJf7ihDKh7I6
Content-Type: text/html;
charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
On Sunday 30 November 2008 09:01:31 Pierre Stirnweiss wrote:
>
> This is what I propose:
> - keeping the idea of "macro command" which parents any subsequent "undo
> command" created after undoCommandAdded signal, I would like to avoid
> having "opened command" at the end of a user action. This is as far as I
> have seen so far only the case for text keying. I think we could use the
> merging facility in that case. That would make things clearer. I will try
> an implementation, and commit if it compiles/work with correct behavior.
>
> - then, I would like to group everything that is related to a user action
> in one place. For example, I don't see why a new paragraph action (this is
> just one example, I am pretty sure there are others) is half made in the
> TextSelectionHandler and in the TextTool. This is confusing and a hell to
> debug.
>
I have committed a working version of the above. To summarize what I have done:
- the text tool public interface has not been changed.
- in the private part, the following was done:
i. declare an enum of editing actions. this is used for the merging test (for implementing QUndoCommand::id()
ii. transfer the declaration of UndoTextCommand from the addUndoCommand method to the header, the implementation is in the cpp file. This is to make it accessible from friend classes
- I have created two "commands" derived from QUndoCommand in the command subdir: the TextInsertTextCommand and the TextInsertParagraphCommand. both are declared friend of the TextTool.
These commands explicitly set themselves as the m_currentCommand in the TextTool at the begining of their cstr and set back the m_currentCommand to 0 at the end. In between, all the changes to the document are done (minus the removal of inlineObjects, which I have not yet looked into, still TODO).
That way all the undoCommandAdded will create a UndoTextCommand parented on the current command. When the command is finished, the currentCommand pointer is reset so no further commands are getting eaten up.
The TextInsertTextCommand checks whether it can merge with a previous one. If so, the commands are merged, "transferring" the child UndoTextCommands to the new common command.
The TextInsertParagraphCommand does not merge with the insertText. That behavior was done on purpose (see previous post), but can easily be modified.
I think grouping all editing actions of a single user perspective action into one single object is actually clearer and easier to maintain down the road.
It might also help with the call of Florian for making the undo/redo available to other tool, I am not really sure what is exactly needed there but would be glad to look into it also.
If this solution is acceptable for everybody, I have already most of the editing actions ready.
Pierre
--Boundary-00=_2ouMJf7ihDKh7I6--
--===============1358865950==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
--===============1358865950==--