On 11 September 2012 10:46, Inge Wallin <i...@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 _______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
