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

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

On Monday 09 April 2007 08:22:10 Thomas Zander wrote:
> On Sunday 08 April 2007 23:42, Pierre Stirnweiss wrote:
> > > Yes, I think you want to use the signal.
> >
>
> What I'm curious about is why you are so fucussed on the undo / redo
> actions integration?
> I really don't see the connection between track changes and commands.
>
I don't want them to be integrated. I need the track change to be aware of the 
fact that undo has been done (that one is easy) and what exactly the editing 
action this undo was (this is were the problem lies, because of merging). 
This is needed to cancel/remove/... the particular tracked change 
corresponding to the editing action that created this undo command.


> Maybe you have looked at OOWriter which seems to behave like this; but I
> have to tell you, its an entirely unsettling experience to have each
> correction become a separate tracked change.

Actually no, I haven't looked at how OOWriter is doing it. I have actually 
used this function on MS Word a couple of years ago (on Office XP). The thing 
might not be perfect on MS Word (in particular when doing some nested 
operations and how the info was presented to the user) but overall I found it 
was pretty intuitive as far as the tracking of the changes is concerned.

>
> Why I don't see the tracking and undo commands as connected is due to what
> I think the end result should look like.  So lets see if we actually are
> talking about the same feature here;
>
> Albert finished a document and sends it to Bonny, his secretary. She will
> look over the document and fix any language, grammar and other problems
> before the document is send to the client.  B. Changes words like 'then'
> to 'than' and she adds some sentences and she removes some sentences.
> When B is finished she saves the document and sends it to A for him to
> look at.  A will then check which changes have been made to see if what
> he meant to say has not been lost.

Yes we are talking about the same thing there.

>
>
> When I type a new sentence, I tend to make some typos, which I correct by
> pressing backspace and then I keep on typing.  In all word processors
> that amounts to 3 undo commands.  1 for the part typed, 1 for the
> removed, 1 for the continued typing.

Yes, both for the undo/redo and for the tracked change, 
these should be merged. I am not advocating to integrate the two together but 
they should be consistent in their merging behaviour.

The problem in your example is if B uses undo instead of backspace to correct 
what was done (perhaps unlikly, but still possible, for the typing but 
probable if it was some formating), neither the 
contentsChange signal nor the undo/redo signals are detailed enough.

> So, from my perspective the track changes code would do something like the
> following;
> * it monitors all changes by listening to the signal on QTextDocument

As I said, this signal is, to my mind, just not detailed enough:

B puts the cursor at pos 10
- deleting the char and undoing the delete will trigger contentsChange(pos=10, 
char del=0, char added=1) for the undo
- typing a single letter will also trigger contentsChange(pos=10, char del =0, 
char added=1)
- formating (expl bold) the 10th char will trigger the exact same signal
- undoing this formatting or adding another formating (italic) to it will also 
trigger this signal with the same args.

so listening to the signal on QTextDocument is not enough.
>
>
> * it ignores all zero-length changes.
yes, these are the ones I refered to as not undo/redo actions

> * textual changes made are recorded. If text is added, then we can just
> copy it from the document. If text is removed we might want to do
> a 'undo', 'fetch text', 'redo' cycle to figure out what that was.
> * Text changes are merged with already made changes so the above example
> of 3 undo commands will really be 1 change in the tracked changes.

this is what I was talking about when I said I would need to mimic the merging 
of the undo/redo stack of the QTextDocument (<> from the canvas stack). I was 
looking for a "cleaner" solution (the suggestion for Qt notifying of a unique 
ID for each editing "commands"). It would work as follow:

when a change is made on the QTextCursor (insert, formatting,...) which 
creates an "undo command" internal to QTextDocument (the "internal" 
QTextUndoCommand) a unique, persistent ID would get generated and passed back 
to the caller (instead of returning void). If the command was merged, the ID 
of the action it has been merged into would be passed back.
The caller could notify the ID together with the exact change that was done to 
the the changeTracker. Undoing/redoing this internal action would send a 
signal with this unique ID. The changeTracker could listen to this and flag 
the corresponding change as being there or not. On saving, the "active" 
changes would be saved using the OASIS syntax.

> * When the user presses undo, he changes text.  This is just a tracked
> change that gets merged with the other changes. No special treatment
> needed.
>
once again here, the documentChanges signal is not verbose enough.

Hence my initial idea of having each undo/redo command (the ones created on 
the KWCanvas stack) notify the trackChange of the actions. The problem there 
is that these are created as a result of the UndoAvailable signal. This one 
is not sent if an editing action was merged into the previous one (typing two 
letters in a row).

> You referenced the side of Albert; when he gets the document from Bonny
> and can either accept or reject the changes.
> This has to be done without any commands being present as the undo stack
> is not stored in a document.
>
The accept action in itself should be a "command" because you want Albert to 
be able to change his mind and after having accepted the change just press 
undo (whether the KWCanvas undo/redo or a specific undo/redo).

> So, technically;
> A text tool has an action to switch on track changes.
yes

> A text tool has a variable; a ChangeTracker class. This class is listening
> to the document signal.
listening to the changes is where I have a problem.

> When changes are made the ChangeTracker registers them and merges changes.
yes.

Pierre
_______________________________________________
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]