The QQmlTableInstanceModel can derive the QModelIndex itself from the flat index, so there is no need for a separate object(QModelIndex) overload. Amends de4b7283c978ca384f6c8bf9f27387158804b601 Change-Id: I9dfff8026ef0acca660f1211b0e453c46562985f Reviewed-by: SanthoshKumar Selvaraj <santhosh.kumar.selvaraj@qt.io> (cherry picked from commit e635da3faf6dac654b2591204162a217a6f02766) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
When Drag.dragType is Automatic and Drag.active is bound to e.g. DragHandler.active, calling setActive(true) previously invoked startDrag() immediately, which in turn called QDrag::exec(). That exec() call enters a nested event loop, which is incompatible with being called from within a QML binding or JS expression: the QML engine is still mid-evaluation when exec() blocks, so when the pointer release arrives in the nested loop, deactivates the DragHandler, and causes the binding to re-trigger, the engine detects a binding loop. Fix this by deferring the startDrag() call via Qt::QueuedConnection so that the current JS frame unwinds completely before exec() runs from a clean event-loop context. An 'if (d->active)' guard in the deferred lambda handles the case where the drag is cancelled before the queued call fires. The executingNativeDrag flag is now set/cleared around exec() inside startDrag() itself (covering both the Automatic binding path and direct QML calls to Drag.startDrag()). It suppresses re-entrant setActive(false) calls that arrive via DragHandler deactivation while exec() is blocking, since startDrag() already handles all cleanup when exec() returns. Fixes: QTBUG-144006 Change-Id: I9bf6a4e6f3edea7e12e187b5756ab483c462696a Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Konsta Alajärvi <konsta.alajarvi@qt.io> Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io> (cherry picked from commit ae6e67e4cf23af6dbceab5e62881864b3a38c867) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Pick-to: 6.8 Axivion-Id: qt_Essentials_qtquick_dev_linux:SV1543 Axivion-Id: qt_Essentials_qtquick_dev_linux:SV1544 Axivion-Id: qt_Essentials_qtquick_dev_linux:SV1549 Axivion-Id: qt_Essentials_qtquick_dev_linux:SV1741 Axivion-Id: qt_Essentials_qtquick_dev_linux:SV1803 Axivion-Id: qt_Essentials_qtquick_dev_linux:SV3062 Axivion-Id: qt_Essentials_qtquick_dev_linux:SV3128 Axivion-Id: qt_Essentials_qtquick_dev_linux:SV3129 Axivion-Id: qt_Essentials_qtquick_dev_linux:SV3130 Axivion-Id: qt_Essentials_qtquick_dev_linux:SV3134 Axivion-Id: qt_Essentials_qtquick_dev_linux:SV3135 Axivion-Id: qt_Essentials_qtquick_dev_linux:SV3136 Axivion-Id: qt_Essentials_qtquick_dev_linux:SV3137 Change-Id: I4427a85cfa6050d43ccd74bd354af3301c802151 Reviewed-by: Christian Strømme <christian.stromme@qt.io> (cherry picked from commit c570680474bcd5f098e1fda4c05bb46885e5bc3a) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
When edit() is called, consult QAbstractItemModel::buddy() first to resolve the target index. This allows the model to redirect editing to a sibling cell, matching the behavior of other Qt item views like QTreeView and QTableView. The included test verifies that we now respect the buddy. The checkEditAfterReorder() test also had to be modifed slightly. It assigned a QVariant(QSharedPointer(QAIM)) as model to TableView, and not the expected QVariant(QAIM). This strangly works in most cases, but will now cause a warning in canEdit() since the variant cannot be casted directly to a QAIM. Change-Id: I01092228019c91212c601f104f5f2fa3274e74e0 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> (cherry picked from commit b2af284eac4aa0e936c42c4c62a9fe14c9ab6916) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
When delegates are sized relative to the view (e.g. height: ListView.view.height), resizing changes all delegate positions. The content position becomes stale, and fixup() calls snapItemAt() with that stale position, snapping to the wrong item. Record the currently snapped item in geometryChange() before layout runs. In fixup(), use the saved index to override the snapItemAt() result, so the correct item is picked with all existing header, highlight, bounds and animation logic preserved. The hint is reset in fixupPosition() after the fixup pass completes. StrictlyEnforceRange is excluded because its fixup() path already forces currentItem as the snap target. Fixes: QTBUG-112349 Fixes: QTBUG-44449 Change-Id: Ie766a4d8641bd2410116c468afc27c8bc25b9f16 Reviewed-by: Vladimir Belyavsky <belyavskyv@gmail.com> (cherry picked from commit 8a99e83213c674ac2946ded86b1aec70c5af63f8) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
positionAt(0) can make inaccurate estimates in cases where the target element is outside the cache buffer, and the list contains section headers. However, since the beginning is a well-known position we can just scroll directly to that position instead. If we do, markExtentsDirty after clearing the visibleItems, to prevent an issue that could occur when setPosition(0) gets called with a stale extent. the extent must be recalculated, in order to be precise, and take into account if the first item has a section or not. Fixes: QTBUG-132694 Change-Id: I51e0634e685d56d1ab341c31f79a8e89cfa6f5c0 Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io> Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io> (cherry picked from commit 9111e967bf54e8fc6644727d334ebfdaf3b59a28) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
When a ViewportOnly rebuild is triggered in TableView by a row or column insertion or removal, delegate items that survive the operation (i.e. are not part of the removed range) should not be pooled and reused. Instead they should simply stay in place and have their context properties updated to reflect any shift in flat index, row or column. This avoids a full pool cycle, preserves any ongoing visual state such as animations, and suppresses unnecessary pooled/reused signals. To achieve this, released items are now staged in a temporary m_releasedItems cache rather than moved directly to the reuse pool. During the rebuild, resolveModelItem() first searches the cache for an item whose QPersistentModelIndex matches the requested cell. If found, the item is reclaimed directly. Once the rebuild is complete, commitReleasedItems() transfers any remaining cached items (those whose cells genuinely disappeared) to the reuse pool, like before. In order to achieve this, a new QPersistentModelIndex is stored on each delegate item. That way we know which cell it originally belonged to, even after changes to the model shifted its row and column position. A new auto-test, verifyThatOnlyRemovedRowsArePooled, is included that verifies the new expected behaviour. The changes in this patch also uncovered that the test model used throughout in the test file was implemented with too many assumptions, and therefore needed some TLC. Fixes: QTBUG-116650 Fixes: QTBUG-134741 Change-Id: I0b935320b6e7dca215df438f5981a154a8c10385 Reviewed-by: SanthoshKumar Selvaraj <santhosh.kumar.selvaraj@qt.io> (cherry picked from commit de4b7283c978ca384f6c8bf9f27387158804b601) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
When a QQuickPopup is open inside a QQuickWidget, pressing Tab on the last focusable item in the popup would move keyboard focus to a widget outside the QQuickWidget instead of cycling back to the first item in the popup. QQuickItem::nextPrevItemInTabFocusChain() has a parameter `warp` which is used by QQuickWidgets and embedded windows. To prevent wrapping between the first and last focusable items in the QML scene. This was working as intentional, with the exception that it would ignore cases when the current focused item is inside a tab fence. In such cases, we still want the item to wrap, we just want it to wrap inside the tab fence, which nextPrevItemInTabFocusChain() already takes into consideration, as long as we don't return early when wrap=false. Fix it by only returning early from wrap=false, when not inside a tab fence. Fixes: QTBUG-138101 Pick-to: 6.10 6.8 Change-Id: Iab0914161f0a80c3b0df0385cfb1fd0c0027ac7a Reviewed-by: Doris Verria <doris.verria@qt.io> (cherry picked from commit 77c3189bc00ebd302b5a211d039db49228dca105) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
When a Text element uses StyledText with <br> tags, maximumLineCount, wrapMode: Wrap, and elide: ElideRight, constraining its width could cause implicitWidth to grow far beyond the correct value. The root cause is twofold: 1. The loop that creates unwrapped lines for implicit width calculation used '<=' instead of '<', causing one extra line to be created and finalized beyond maximumLineCount paragraphs. 2. The multiline-elide code path creates a trailing line via createLine() to compute the elided text. That line is left unfinalized, so endLayout() finalizes it at QFIXED_MAX width, inflating maximumWidth(). Finalize it at zero width right after use. Fixes: QTBUG-142933 Change-Id: I64bab9512b8400ed63a4dda709259488a2b49a21 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> (cherry picked from commit 021778a0ad7d5758cee5f5592017e46b4e12171d) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The class' setup() and render() methods are always executed on the renderer thread, while all other methods are executed on the main thread (or any other user thread). That way, we have a potential race condition when accessing the members of QQuickItemGrabResultPrivate. Fix it by adding a mutex. Note that we cannot hold a mutex when executing a callback or emitting a signal, because this can lead to a deadlock is the slot or a callback use the getters. Extend the existing test cases to cover these scenarios. Pick-to: 6.8 Change-Id: I03cc556975f783c630f29ec648306f3cd604ed16 Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io> (cherry picked from commit 055e06e435ee227e79239548d2873b1bcc32ecc2) Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>