Distraction free writing mode

[Inge Wallin]

On Tuesday, September 11, 2012 09:12:04 C. Boemann wrote:
> 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

I see only 3 alternatives:

1. What you suggest above, i.e. copy the (some?) text parts of Qt into 
Calligra and hack it into something that fits our usecases.

2. Use something else, e.g. the text layout from Abiword, provided it can be 
used from a license point of view, and give it a Qt API.

3. Continue what we have and either create more and more elaborate workarounds 
or not do some things at all, like DFM or change tracking.

Provided it is now a real decision to go with alternative 1 (which I am in 
favour of), here is what I suggest:

Phase I: I think we should fork it asap. This can be done more or less 
immediately since it doesn't need any other change whatsoever in Calligra 
except a change in some link lines in CMakeLists.txt

Phase II: After that we should add our patches that we already have, like the 
one you refer to above (bidi) and the visibility patches that will allow 
change tracking.

Phase III: We are now ready to start (re-)implement the features that are the 
reason we are doing this at all. They should be done in our normal way of 
developing the features in a branch and then put them up for review.

My guess is that phases I and II could be rather quick. Phase I should be done 
by one individual who knows the code well (that would probably be boemann) and 
Phase II could be done by a small group, e.g. PierreSt and boemann. I am 
willing to put some time into it but I am not that familiar with the deep 
parts of the code and may not be very efficient. 

Once phase III starts, it is the responsibility of a person who needs a 
certain feature to implement it both in the user-visible layers and in the 
lower-level layer. The phases I and II opens up the possibility to implement 
the new features that we all want, but we still have to do the work ourselves.

One possible exception to the last paragraph is the separation of content and 
styling so that we can apply new styling without getting a lot of undo 
records. We may want to set up a small group that designs and implements this 
as a separate project. I am willing to be part of that group.



> _______________________________________________
> calligra-devel mailing list
> calligra-devel at kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel