The commercial license was updated to source files in df8183117bf244e22c96151f798a1f8f8134e960. Change-Id: Id4d5bf211cafdb56b8bda02fb7b6ea61bd8e7878 Reviewed-by: Jani Heikkinen <jani.heikkinen@qt.io>
Qt 5.15.17-lts release Change-Id: I85da10a6f1030e50730c7aaee4c71ae861f1ecc4
Qt 5.15.16-lts release Change-Id: I2892ad4097deaec565b10357ca61be10048a7c81
Qt 5.15.15-lts release Change-Id: I0272e1ec4b55be362e13e36cd48f532fe4b7c770
Change-Id: I1931a83a9be70494c53bb0a79b3bcb01f6c84608
The SwipeView's page did not change to a new page when the user right-clicked on text content inside the page. This occurred because the mouse press event enabled the 'pressed' variable, indicating the beginning of a drag. Since the text item did not accept the press event, there was no need to handle the move and release events. Consequently, the 'pressed' variable remained true. If the 'pressed' variable is true, then the SwipeView's contentItem does not update the highlight item. This implies that the highlight animators will not start. Consequently, although the current index and item would change, the content item view is not updated. To fix this issue, the 'pressed' variable should not be true when the press event is not accepted. When it's a mouse event, the value of the 'pressed' variable is set to true when the left button is pressed, similar to the existing condition in the handleMoveEvent() method. Since the bug originated in 'maybeBeginDrag()', the condition is added to this method by passing the event's buttons. The testcase creates a SwipeView component with two page items that include a Label item. The test involves performing mouse and touch events on the text content. Subsequently, when the current index is changed, the testcase compares the content item to ensure it is adjusted to its position to display the current item accordingly. [ChangeLog][Quick][Flickable][Drag] Flickable is meant to be dragged (flicked) by touch events; and as a matter of legacy support, for now it can also be dragged by the left mouse button. Dragging with other mouse buttons, such as the right and middle buttons, is not allowed. Task-number: QTBUG-97252 Pick-to: 5.15 Change-Id: Ice23650dd29fe400b80efe299c9294fad62dcefb Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
2^30 was used as a "big number" sentinel and assumed to always be higher than the particle system's age. But a particle system running for a bit over 12 days will hit this limit. The result was that such particle systems would never exit the loop in recycle() and deadlock. Instead we add the check for an empty heap to the loop condition itself. Fixes: QTBUG-123111 Change-Id: I6bf9c5a27271e74f56728c0ad7bdabdd87e028b2 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> (cherry picked from commit 9c54252914634a6756b39261b027b48b96c6ea7b) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org> (cherry picked from commit fd53ed433a18a369984d87614921bbeed92997b1) (cherry picked from commit c34daa62e6efad6566fab478c3f937030f1828fb) (cherry picked from commit 2a389f2575219de6d8d264a6e244a0420ee92b87) (cherry picked from commit 4ca3d4a24a39547163046766989255f199c51b84)
This test runs slow with MinGW builds. It can take more than 10 minutes to run it. Not the ideal fix, but since this is deprecated for Qt 6 there is no point in investing too much time into fixing it. Task-number: QTBUG-84339 Change-Id: I22e9a865ef7d2dafad482028b698b50c8370b1b1 Reviewed-by: Tarja Sundqvist <tarja.sundqvist@qt.io>
When OpenNebula was updated in CI, new Windows provisions defaulted to 800x600 resolution which caused some tests to fail. Adding new display settings to the Windows registry in tier-2 provisioning scripts worked on Windows 10/11 but issues with Windows 7 persists, one of my suspicions is that Windows 7 VM spawns a new empty video subkey in the registry when it's launched by a module in Coin run, which happens after provisioning scripts are run and done. This issue is blocking Qt 5.15 integrations, so for now it is best to blacklist the tests that fail from the 800x600 screen resolution. Task-number: QTQAINFRA-6145 Change-Id: I66480bb4b0a905f0a42c447ccb549c1e2125f9c8 Reviewed-by: Tarja Sundqvist <tarja.sundqvist@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
The application could call mlockall(MCL_CURRENT|MCL_FUTURE) to lock all its memory for performance reasons, causing the madvise call to fail. There's no need to crash. Instead, manually zero-out the memory when decommitting. Fixes: QTBUG-120450 Change-Id: I6f1a8968853cc5e61561371bd2a435a686eaf0e4 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> (cherry picked from commit 524d260c5c135d193e06350e48357444ddb13ddb) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org> (cherry picked from commit 1ead022dfea5a6b3bed8ca80de85c20cea6c809f) (cherry picked from commit a2e0061317954fdab6f9af1ab0490944bca33873) (cherry picked from commit 5c42f57e88681be521e3d59f9e527d3bcd4d5732) (cherry picked from commit cb8ecdbf482d11c01115964e345f132a65bc365f)