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

List:       koffice-devel
Subject:    Change tracker and commit problem
From:       Pierre Stirnweiss <pierre.stirnweiss () t-online ! de>
Date:       2008-11-24 22:04:50
Message-ID: 200811242304.51011.pierre.stirnweiss () t-online ! de
[Download RAW message or body]

Hello everybody,

first I wanted to commit the changes to the branch work/koffice_trk but somehow 
it was committed to trunk. I have to say that I do not know what happened or 
what has gone wrong. So if the powers that be deem necessary to uncommit, 
please do.

The commit should however be safe as all the modifications have been defed out 
at compile time (with the var CHANGETRK in the root CMakeList.txt).

Everything compile (when the code is enabled). The only thing I am not sure 
about is the effect (of the new code when enabled) on tests as the forth one 
seem stuck and I have not managed to define a timeout.

Now, on the changetracker itself, which I wanted to get your approval first 
before committing to trunk.

The changes are tracked by adding a property to the QTextCharFormat. The 
property value is the changeId given by the changeTracker.
So far, as a proof of concept the following actions are tracked : Bold, Italic 
and keying text.

On saving, the implementation is inspired from the style saving. All changes 
are store for each fragment as KoGenChange in a KoGenChanges object. This 
object saves the XML.
I did not implement this on the KoShape level but rather into the KoTextShape 
level. This is because that way there are less parts of Koffice that are 
impacted and also because it seems that only text documents have a change 
tracking section in the OASIS spec.

For that I had to sub class KoShapeSavingContext into KoTextShapeSavingContext 
(which get the KoGenChanges as argument). The only catch here is that on 
creation of a TextShape, the savingContext that should be passed must be of 
the KoTextShapeSavingContext type.

Saving actually works and as far as I can tell, the odf generated is conform.

The reason I went for storing the change in the charformat, as opposed to 
handling this by the changetracker is that it is much safer and more robust 
when inserting, deleting, etc. That way, you do not actually need to all the 
time keep track and update the position of the changes that were previously 
stored, QTextDocument does it for you and for free.

I am open to suggestions and plan to:
- make sure all the TextShapes created througout koffice pass actually a 
KoTextShapeSavingContext instead of the KoShapeSavingContext
- track all the other actions.
- implement the loading of the stuff.
- implement the gui to view the changes
- implement the framework to accept/reject changes.

All this would be done defing the stuff out until the code is actually deemed 
OK.

I would still rather do it on the trunk because keeping a separate branch up 
to date is a real pain.

I would be happy to discuss this.

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]