[Development] QTextFragment visibility option

Simon Hausmann simon.hausmann at nokia.com
Tue Jan 17 15:48:28 CET 2012


Hi Pierre,

On Monday, January 16, 2012 10:57:28 AM ext Pierre Stirnweiss wrote:
> 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.

I can see now how you'd be able to implement tracking with this, but I wonder 
how much more complex this makes your layout altogether, because hidden 
fragments are right now subject to the layout and they're always visible in 
content (i.e. the number of characters in the document).

One idea Lars and I had when discussing this was to extend the fragment tree.
The block tree uses this idea to calculate the block number by extending the 
size_array/size_left_array. A similar approach could be used to separate the 
visible from the invisible fragments and keep them in sync at the same time.

The main issue with that approach is that it pessimises the common case in 
terms of memory usage and it is a compile time decision.
 
> 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.

Can you elaborate a bit how fragment visibility helps with the implementation?
Are those _supposed_ to be part of the content/undo-redo but you just want to 
toggle their visibility?
 
> 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.

This sounds tricky though, because there's currently no way to forcibly split 
a fragment. I guess you'd also need that?
 
> 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.

I've added some comments to the patch. It will require at least one iteration 
:)

I think we can proceed with the fragment visibility, but it needs to be 
consistently implemented. I'll explain that in Gerrit.

Simon



More information about the Development mailing list