Distraction free writing mode

[Jaroslaw Staniek]

On 11 September 2012 10:46, Inge Wallin <inge at lysator.liu.se> wrote:
> 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

[..]
For forks of Qt-only software, assuming it's going to be independent
of anything in Calligra, how about creating separate
subproject/repository?
This would potentially get more developers on board, and in some
distant future, could become more like a subproject of Qt.

(I've started this with kexidb -> Predicate -- work in progress but
still the potential audience is dramatically larger)

-- 
regards / pozdrawiam, Jaroslaw Staniek
 Kexi & Calligra & KDE | http://calligra.org/kexi | http://kde.org
 Qt Certified Specialist | http://qt-project.org
 http://www.linkedin.com/in/jstaniek