Odd deferred layout behaviour with a Flickable of a Column of Columns...
-
Just had an interesting encounter with this:
I have an app with a Flickable containing a Column (
id: content
) containing a Repeater and the repeater's model component is another Column (id: record
) with some Text and Image and Rectangle items in it.It's look-and-feel is exactly as expected... however when I added some external js to dig into the
content
items children looking for certain items (identified by a particularobjectName
) and using their position relative to the Flickable'scontentY
andcontentHeight
to trigger display of some "top level" UI stuff not in the Flickable... I got some unexpected behaviour, and a bit of logging confirms it's as if the innerrecord
Column items aren't laid out until they're actually scrolled into view in the Flickable. Before that, they
of therecord
s' child items is unexpectedly zero.(A consequence of this was that the first time scrolling through the Flickable, the triggered stuff was being triggered prematurely. But then once everything was forced to be laid out and the
y
values were correct, everything behaved as intended while scrolling back and forwards again).There's some hint that Column might be doing something clever from the mention of
forceLayout()
in the docs. I couldn't figure out where to drop aforceLayout()
into my code to get it to behave any better though.I eventually worked round it by replacing the inner
record
Column with a straight Item, and anchor-based placement of its sub-items... then the y positions of the sub-items seem to be as expected from the start. But I'd like to understand what's going on better.Is the behaviour I saw with Column better documented anywhere? Are there other component types which defer layout calculations until they're "in view"? Is this "in view" behaviour specific to Flickable, or other things? Is there any way of tapping into it (a signal or something?) or does it just naturally fall out of QML's just-update-what's-needed approach somehow?