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
ToolTipthat 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
RangeSliderwhose properties are bound by a numeric readoutLabelat 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
- An instant search based on what has been typed in a
-
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. -
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
ToolTipthat 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
RangeSliderwhose properties are bound by a numeric readoutLabelat 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
@barbicels what's your JDK and NDK and have you tried 6.11.1 ?
- An instant search based on what has been typed in a
-
@barbicels what's your JDK and NDK and have you tried 6.11.1 ?
-
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.I'm familiar with the practice of using the
Overlay.overlayattached 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.
-
@ekkescorner NDK is 27.2.12479018 and JDK is 17.0.2, acceptable according to Qt Creator.
@barbicels yep, that's ok. 6.11 needs JDK 21
-
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.@mskyyyf-wiieyy
I'm not clear on what theMouseAreaaccomplishes 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 toOverlay.overlayand thus be immune to all the effects of the layout passes that result from those interactions. Correct?
