On Tuesday 11 September 2012 08:56:37 Pierre Stirnweiss wrote: > > > There is perhaps a way, that i started to explore for change tracking > > > without much success (but i didn't pursue this very long). It seems > > > possible to specify additional formatting at layout stage (QTextLayout > > > class I think). I don't know how usable this is. Camilla should know > > > much more than me about this one. > > > > Unfortunately it's very limited and doesn't begin to cover what we will > > need > > from it. > > > > Well, we then really need to make a decision, which is better be very well > discussed and thought out. > The situation is the following (add some if I have missed any): > > Current QTextDocument/QTextLayout does not allow us to do: > > - *change tracking*: we want to be able to display/hide tracked changes > inline. For this we need to be able to switch visibility on a text > fragment. The way I believe it should be working is that we would put a > flag/text property on a text fragment. At layout stage (line lay out within > QTextLayout internal), we would ignore these fragments. > - *DFM writing*: we want to be able to display/hide text formatting. This > IMHO should also be handle within QTextLayout internal layouting/drawing. > It is after all purely a display option. The document content/formatting is > not changed. > - *something about Bidi I can't remember* > > Now, we have so far managed to work around these limitations one way or > another. The solution I am proposing for DFM (ie having different versions > of each style), can be used for implementing it, although there is the > problem of the undo/redo action it will create (same problem as when > switching show/hide changes in change tracking). Independently of DFM, I > think having "style profiles" would still be a killer feature both in Words > and Author (I can look into this while I am through with parent style > saving), and for this sole use case, the undo/redo action actually should > be created. > > > So the question is: is it time for us to fork QTextDocument/QTextLayout in > order to implement these properly? The main problem is the maintenance > burden. However I am not sure it really would be that much, I think these > classes are now really mature and won't change that much. However, since I > personally don't have the time to do all this, the decision is not mine. > > Pierre Yes I think it sums it up quite nicely (at least if you have the background knowledge)
getting the changetracking stuff into qt5.1 should be possible, but we have the bidi+indentation issue which it seems we cannot get fixed, so from that alone it would make sense to fork qt indeed well the text part of qt I think that decision is taken for us by the qt text maintainer not wanting to accept the bidi patch. Questions just when we do it, and who does the hacking _______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
