<![CDATA[Qt 6.10.3 Android: layout changes defeat drags, text input]]>Many Android developers have reported that changing the state of Qt Quick controls can cause the Android OS to "rebuild" the corresponding views in its layout. That seems to be causing multiple problems in my code with GUI actions like drags and continuous typing that result in automatic changes to other Qt Quick controls.

For example:

  • An instant search based on what has been typed in a TextField (without waiting to press Enter) causes the text field to lose focus and the soft keyboard to close, because the change in the geometry of controls showing search results causes a layout rebuild; it is as if the underlying text view has been deleted and recreated.
  • A ToolTip that is programmed to appear when tapping and holding a button closes immediately or does not appear at all, as the layout rebuild appears to "untap" the button.
  • A RangeSlider whose properties are bound by a numeric readout Label at each end can only be dragged one step at a time, because changing a label's text causes a layout rebuild and kills the drag.

Our code is too complex to share here, but I'll point out that all of this code works perfectly on iOS, where the association between a Qt Quick control and the OS's underlying view is permanent across layout actions.

Has anyone faced this problem, and managed to overcome it? The last thing I want is to have to throw in a time delay so that the GUI action can be continuous.

Environment: Android 16, Qt 6.10.3

]]>https://forum.qt.io/topic/164702/qt-6.10.3-android-layout-changes-defeat-drags-text-inputRSS for NodeMon, 01 Jun 2026 16:56:18 GMTMon, 25 May 2026 01:45:12 GMT60<![CDATA[Reply to Qt 6.10.3 Android: layout changes defeat drags, text input on Wed, 27 May 2026 00:59:14 GMT]]>@mskyyyf-wiieyy
I'm not clear on what the MouseArea accomplishes in that solution, but I think you're telling me that any interactive control like a slider or a live-search text field should be parented to Overlay.overlay and thus be immune to all the effects of the layout passes that result from those interactions. Correct?

]]>https://forum.qt.io/post/838388https://forum.qt.io/post/838388Wed, 27 May 2026 00:59:14 GMT<![CDATA[Reply to Qt 6.10.3 Android: layout changes defeat drags, text input on Mon, 25 May 2026 15:54:55 GMT]]>@barbicels yep, that's ok. 6.11 needs JDK 21

]]>https://forum.qt.io/post/838373https://forum.qt.io/post/838373Mon, 25 May 2026 15:54:55 GMT<![CDATA[Reply to Qt 6.10.3 Android: layout changes defeat drags, text input on Mon, 25 May 2026 15:52:14 GMT]]>@mskyyyf-wiieyy

I'm familiar with the practice of using the Overlay.overlay attached property to parent an item that floats above the window (with geometry in global coordinates). In our case, the stuff that needs re-layout is part of the same scrollable Qt layout as the controls whose changes cause that to happen — all pretty normal mobile-app behavior — so I don't know how I would make that work.

Can you point me to a minimal working example of this? That would be fantastic.

]]>https://forum.qt.io/post/838372https://forum.qt.io/post/838372Mon, 25 May 2026 15:52:14 GMT<![CDATA[Reply to Qt 6.10.3 Android: layout changes defeat drags, text input on Mon, 25 May 2026 15:19:16 GMT]]>@ekkescorner NDK is 27.2.12479018 and JDK is 17.0.2, acceptable according to Qt Creator.

]]>https://forum.qt.io/post/838371https://forum.qt.io/post/838371Mon, 25 May 2026 15:19:16 GMT<![CDATA[Reply to Qt 6.10.3 Android: layout changes defeat drags, text input on Mon, 25 May 2026 14:26:55 GMT]]>@barbicels what's your JDK and NDK and have you tried 6.11.1 ?

]]>https://forum.qt.io/post/838370https://forum.qt.io/post/838370Mon, 25 May 2026 14:26:55 GMT<![CDATA[Reply to Qt 6.10.3 Android: layout changes defeat drags, text input on Mon, 25 May 2026 11:09:15 GMT]]>Ugh, I’ve fought this exact same issue on Android Qt! The view rebuilds are brutal, especially with anything interactive like sliders or live search.
A trick that helped me: wrap the dynamic parts of your UI in a MouseArea and use QtQuick.Controls.Overlay for elements that don’t need to affect the layout directly. It prevents the geometry changes from triggering full layout passes mid-interaction.
Also, double-check that you’re not binding properties that trigger implicitWidth/implicitHeight updates unnecessarily — those are usually the culprits.

]]>https://forum.qt.io/post/838365https://forum.qt.io/post/838365Mon, 25 May 2026 11:09:15 GMT