[Development] QTextFragment visibility option

Pierre Stirnweiss pstirnweiss at googlemail.com
Mon Jan 16 10:57:28 CET 2012


Hello everybody,

As it is my first post in that list, a bit of presentation is due: my name
is Pierre Stirnweiss, and I am part of the Calligra (www.calligra.org)
team. I initially started coding in KOffice time, with the initial
implementation of the change tracking system.


We (as in the Calligra team) would like to discuss a feature we need from
the QTextFragment: being able to toggle the visibility (ie, laying out and
painting) of a specific QTextFragment.


1. the initial use case for Calligra Words: change tracking for deletions.

When tracked, a delete text fragment shouldn't actually be sent to limbo:
it should be marked as "deleted".
When the text is visualized with highlighting the changes, the deleted
fragments can be displayed in 2 ways: inline or as side notes. When the
text is visualized without highlighting the changes, the deleted fragments
shouldn't appear at all.

We want to implement the display of changes inline, hence the need of being
able to layout/draw text fragments depending on the "show/hide changes".
For now, Qt does not allow to not layout/display a fragment of text.
The way we are currently working around that problem in Calligra is the
following: when the user "hides" the changes, the deleted fragments are
actually deleted from the QTextDocument, when the user toggles to "show
changes" the deleted fragments are re-inserted in the QTextDocument. The
problem with that solution is first that this creates an undo/redo
insertion/deletion for what is actually just a "display" option. The second
is that it renders the code in Calligra very complex, especially with
regards to style, save, cursor.

2. second important use case for Calligra Words: substitution characters
for objects (anchors,...).

Although these characters are not "displayed" within the text (because
their size is returned as 0 width), they are still laid out. This means
that on cursor movement, they are not traversed. This means the user need
to press several times the arrow key to go through what appears as a single
cursor position on screen.

3. further interesting use case (but which is not yet that stringent for
Calligra Words): hiding portions of text on demand

This can be interesting for example in case of multiple user editing. Some
portions of text might be irrelevant/confidential (although for
confidentiality, this would be a very very weak solution) for some users
and not for others.
Another use case of that type is similar for example to IDE code folding. I
am not interested in seeing this part of the text (like in IDE an if
block), so I would like to hide it for now.


That is for a bit of background on the use cases.

About a year or two ago, we discussed this problematic of having
visible/invisible QTextFragments. 2 initial ideas for solution appeared:
- have a boolean in the QTextFragment toggling visibility or not. the
layout engine would lay out only the visible fragments.

The advantages of this solution is that since the visibility would be a
layout/display only property, a bool on the fragment wouldn't trigger any
undo/redo actions in QTextDocument. The second advantage is that there is
no need to tweak/touch the text formatting mechanism. The drawback is an
added visible bool member to the QTextFragment API.

- have a "visible" character format. The layout engine would get passed a
flag if it should layout these fragments or not.

The advantage of this is that the visible impact on the API is probably
less. The inconvenient is that setting a character format is triggering an
undo/redo action in QTextDocument. Also, the layout should probably be
tweaked deeper than with the other solution.


Ganesh Paramasivam (who was i think at the time mandated by Nlnet to work
on change tracking in KOffice) started working on this (using the first
solution, which looked like the most logical one) and submitted a patch to
Qt (https://qt.gitorious.org/qt/qt/merge_requests/2274), which triggered
some discussion. At some point the merge request was rejected.

Now with Qt5 coming, it would be a really good time to actually get this to
a conclusion, because this feature is actually really needed.

CBoemann who is maintaining Calligra Words has updated the initial patch
(to avoid the extra memory footprint) and submitted a Gerrit review
request: http://codereview.qt-project.org/#change,13161 for this.



PierreSt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120116/657d9c20/attachment.html>


More information about the Development mailing list