Distraction free writing mode

[C. Boemann]

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