Distraction free writing mode

[Pierre Stirnweiss]

> >
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/calligra-devel/attachments/20120911/87036fed/attachment.htm>