Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. QML and Qt Quick
  4. Odd deferred layout behaviour with a Flickable of a Column of Columns...
Forum Updated to NodeBB v4.3 + New Features

Odd deferred layout behaviour with a Flickable of a Column of Columns...

Scheduled Pinned Locked Moved Unsolved QML and Qt Quick
1 Posts 1 Posters 392 Views 2 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • timdayT Offline
    timdayT Offline
    timday
    wrote on last edited by timday
    #1

    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 particular objectName) and using their position relative to the Flickable's contentY and contentHeight 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 inner record Column items aren't laid out until they're actually scrolled into view in the Flickable. Before that, the y of the records' 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 a forceLayout() 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?

    1 Reply Last reply
    0

    • Login

    • Login or register to search.
    • First post
      Last post
    0
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Get Qt Extensions
    • Unsolved