[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    track change (was : Re: TextTool commands)
From:       Pierre Stirnweiss <pstirnweiss () googlemail ! com>
Date:       2007-04-08 21:42:56
Message-ID: 200704082342.57406.pierre.stirnweiss () t-online ! de
[Download RAW message or body]

On Monday 26 March 2007 13:49:20 Thomas Zander wrote:

>
> > With regards to the KoTextEditingPlugin, it seems that the notifications
> > would not happen on formating changes. The contentsChange signal seem to
> > be emited on format change though.
>
> Yes, I think you want to use the signal.
>
After a couple of experimentations and a lot of reading the code (both of 
TextTool,... and QTextDocument and the like), here is were I stand for the 
track change at which point I need some feedback/help:

- The problem with the signal is that it only tells you something happened. It 
is prety much useless when you want to know what happened (which is paramount 
to properly track the changes with undo/redo). There is no way (I can think 
of) to know from the signal if the change is due to an action being 
undone/redone or to a new action (the pos and nbr of char affected is not 
enough).


- the editing actions are of two types: the one which generates undo/redo 
(inserting/deleting text, applying formating on a selection, ...) and the one 
which does not (changing the format of the cursor with no selection).

- the editing actions which do not generate an undo/redo do not need to be 
tracked as their influence on the document will only appear after another 
action which generates an undo/redo is done (expl. changing the format of the 
cursor (with no selection) will not influence the document until at least 
one char is then inserted)

- the track change needs to be informed when an editing action is applied 
(redo) and cancelled (undo). It needs to know exactly what has been 
done/undone (string, format,...)

- the track change needs to merge its actions in sync with the undo/redo 
stack. This is currently my strongest headache.

- changes can be accepted or rejected. These are actions that can be 
undone/redone.
- accepting a change do not change the document content. It just removes the 
changes from the track change and consider the changes as original content
- on the other hand, rejecting a change changes the document content (or 
formating). this particular change should not be tracked.


- ideally what I think would be great from Qt is the following: any "editing" 
action on a QTextCursor would instead of being void, return an id of the 
undo/redo command it has created or merged with (or -1 if it was not 
an undo/redo). Signals (docChanged, undo/redo, ...) would pass this id (or 
index). That way keeping the two in sync would be really easy.

Would it be possible to include this in Qt (I would be happy to do it if there 
is a chance of it being included)? Otherwise a workaround needs to be found.

All the ones I have thought about so far mimic the QTextDoc undo/redo 
(creating a "tracked object" for each editing actions and merging them the 
same way as QTextDoc does).

I welcome some new line of thoughts cause I am a bit stuck there.
What I need is:
- a way to uniquely identify changes that are made on the doc and have a link 
to the corresponding command.
- a way to know reliably when a command has been merged and with which command 
of the document stack
- a way to know which command has been undone/redone.

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]