aboutsummaryrefslogtreecommitdiffstats
path: root/src/quick/items/qquickitemview.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Revert "QQuickItemView: do not set parent to nullptr upon destruction"v5.15.0-beta1Ulf Hermann2020-02-211-1/+1
| | | | | | | | | | | | | This reverts commit 5445fcac36d7122d533a2bdf0fcfe6206b7f3ff4. The original commit avoids a warning generated for a dubious use case and breaks controls2 in a non-trivial way as a side effect. We should rather live with the warning. Task-number: QTBUG-82368 Change-Id: I6197bb63036cb25ec3e88f549667519b8f3ff13a Reviewed-by: Mitch Curtis <mitch.curtis@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* QQuickItemView: do not set parent to nullptr upon destructionRichard Moe Gustavsen2020-02-141-1/+1
| | | | | | | | | | | | | | | | | | | | Setting a delegate item's parent to nullptr will make any bindings to the parent inside the item invalid, and warnings will as such be printed (first seen after 8c72e634b3b0eacbfdee883bfc34994d3c19ed77). I assume the reason for setting the (visual) parent to nullptr is to immediately hide it. So to avoid trigger any bindings, we instead just cull if from the scene graph. It's also dubious why a delegate should have bindings to its parent in the first place, since what ends up being the parent is an implementation detail, and probably not be the item the user expects it to be. Fixes: QTBUG-81976 Change-Id: I7bd8ab91461504b6e79d4aa2ab832be087245c3e Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* QQuickItemView: only connect recycle signals to delegate modelRichard Moe Gustavsen2020-01-291-4/+8
| | | | | | | | | | Only QQmlDelegateModel has reused/pooled signals. So only connect/disconnect to those signals when the assigned model is of that type. Fixes: QTBUG-81257 Change-Id: I52a39a98ac0f557ff57307572581dc6c7a05af92 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* Merge remote-tracking branch 'origin/5.14' into 5.15Qt Forward Merge Bot2020-01-201-2/+6
|\ | | | | | | | | | | | | Conflicts: src/quick/items/qquickitemview.cpp Change-Id: Ib9faebdbef5eebb80f4e6aeb5b15b5df7494b157
| * QQuickItemView: fix crash when changing modelWang Chuan2020-01-151-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When visible items become invisible, ListView will try to cache them and redisplay these items if necessary. However, we can't cache items when changing to a new model, since the old one will be deleted later Fix by adding a flag to let ListView know we are clearing items and prevent cache unnecessary items Fixes: QTBUG-80203 Change-Id: I50dcd3f0586c93496b143bdad0e59751360501a8 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* | Merge remote-tracking branch 'origin/5.14' into 5.15Qt Forward Merge Bot2020-01-141-12/+16
|\| | | | | | | | | | | | | | | Conflicts: src/quick/items/qquickitemsmodule.cpp src/quick/items/qquickitemview.cpp Change-Id: I02191959a5023c4320f5487a7fb3a71f8711195f
| * QQuickItemView: Fix iteration/deletion logicUlf Hermann2020-01-101-12/+16
| | | | | | | | | | | | | | | | If a QVector has been modified from the outside, all its iterators are invalid. Therefore, we need to do index-based iteration here. Change-Id: I02b850daf6aadd8f8a81cc93b0d295e1170d7dd6 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* | QQuickItemView: Change QHash::insertMulti use to QMultiHash::insertMårten Nordheim2019-12-101-6/+5
| | | | | | | | | | Change-Id: Ib19365258269a01e203359e7dbe1207f14df3758 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* | Merge remote-tracking branch 'origin/5.14' into 5.15Qt Forward Merge Bot2019-12-091-1/+3
|\| | | | | | | | | | | | | Conflicts: src/qml/common/qv4compileddata_p.h Change-Id: I1150c8cd0161f0e22137d383013751394ae64e18
| * QQuickItemView: Emit correct change signal on model resetFabian Kosmale2019-12-051-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As the variable was manually set to -1 beforehand, we would never emit the change signal, leaving bindings stale. However, simply removing the assignment would lead to not triggering the signal when currentIndex was 0. So now we set it to -2, which cannot happen in any other place. Note that QTBUG-64998 was already mostly fixed due to earlier changes fixing the currentItem part, only currentIndex was still broken Fixes: QTBUG-68232 Fixes: QTBUG-64998 Fixes: QTBUG-63422 Change-Id: I885e06f1e258e67c3368d017bf79bff760440863 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* | Merge remote-tracking branch 'origin/5.14' into 5.15Qt Forward Merge Bot2019-12-051-1/+5
|\| | | | | | | | | | | | | | | Conflicts: tests/auto/quick/qquicklistview/tst_qquicklistview.cpp tests/auto/quick/qquicktableview/tst_qquicktableview.cpp Change-Id: Ib46bc1c717cf524eea2fb3d876810c8d55747c91
| * Fix ObjectModel item not being rendered when moved between modelsMitch Curtis2019-12-041-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When moving an item from ObjectModel A to ObjectModel B, polishes are scheduled for the respective ListViews in order: the ListView for A first, and then the ListView for B. However, when it comes time to do the actual polishing via updatePolish(), the list of items is traversed backwards. This means that the following calls var item = objectModelA.get(0) objectModelA.remove(0, 1) objectModelB.insert(0, item) will result in updatePolish() being called for ListView B first, and then ListView A. As a result of this, setCulled(false) will be called by ListView B (since the item is now visible within it), followed by ListView A calling setCulled(true) (since the item is now no longer in it). As there is no way for these models to know about each other (and it's not feasible to store refcounts in QQuickItemPrivate::extraData, since ObjectModel is in QtQml.Models, which can't know about QtQuick), this patch makes ListView check if the item is parented to its contentItem before culling it. This prevents it from hiding items which are no longer shown in its view. Change-Id: If50614ebc269fae875195bbc63c0c04dab237775 Fixes: QTBUG-67986 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* | QQuickListView: implement support for reusing itemsRichard Moe Gustavsen2019-12-041-16/+60
|/ | | | | | | | | | | | | | | | | | | | | | | | | | This patch will implement delegate item recycling in ListView. The API will be the same as used in TableView, except that it will be off by default since the behavior of a delegate that is reused is not compatible with legacy applications which were not written with this in mind. Most importantly: - Component.onCompleted will only be called on a delegate the first time it's created, and never when it's reused. - Any user-declared properties in the delegate (that is, not model roles, index, etc) will not be cleared or updated when an item is reused. The application must do this manually upon receiving the pooled or reused signal in the item. [ChangeLog][ListView] ListView now has support for reusing delegate items. This can be switched on by setting the reuseItems property of ListView to true. Task-number: QTBUG-80507 Change-Id: I68cc8300b050e4a1f89feebb1d31a2fd9189c793 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QQuickItemView: Set moveReason to other on model changeFabian Kosmale2019-12-031-0/+1
| | | | | | | | | | This implements Michael Brasser's suggestion in the bug report. As there do not seem to be other bug reports related to the fixupPosition change, this might already be enough. Fixes: QTBUG-66163 Change-Id: Iee45621ff7081b280626f4a81dab9bd36a7ea6b7 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Merge remote-tracking branch 'origin/5.13' into 5.14Qt Forward Merge Bot2019-11-141-1/+5
|\ | | | | | | Change-Id: I06578422b4558feabf7a77426b01e77953ab60e2
| * Fix a layout bug caused by a delegate item that was moved by the user5.13Jan Arve Sæther2019-11-121-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | The position of the first item in the list of visualItems was used to know how to layout the rest of the visual items. However, this did not work if the first item was actually moved (e.g. due to a DnD operation). We therefore store the position of the first visual item after each time we arrange it, and use that as a basis on where to start layouting from. Task-number: QTBUG-78076 Change-Id: I837f5b7d61a13d98d23287685c6fd66817360906 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* | Merge remote-tracking branch 'origin/5.13' into 5.14Qt Forward Merge Bot2019-10-311-18/+16
|\| | | | | | | | | | | | | | | | | | | Conflicts: .qmake.conf src/qml/common/qv4compileddata_p.h src/qml/types/qqmlbind.cpp tests/auto/qml/qqmlproperty/tst_qqmlproperty.cpp Change-Id: I6a137907e63445f17a3d6181b832a6bd76135bb2
| * Rename some variables and a function to improve clarityJan Arve Sæther2019-10-241-18/+16
| | | | | | | | | | | | | | | | | | * Rename firstVisibleItem() to firstItemInView() to reflect its behavior, as the comment requested ;) * Likewise, rename some related variables Change-Id: I98e25d5d47a4acb56a2b4f2bd75bec062ff770ee Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* | Merge remote-tracking branch 'origin/5.13' into 5.14Liang Qi2019-10-101-4/+13
|\| | | | | | | | | | | | | | | Conflicts: src/plugins/scenegraph/openvg/qsgopenvgcontext.cpp tests/auto/quick/qquickpathview/tst_qquickpathview.cpp Change-Id: I117c8d62b21800329d1035021d312d9924f83a1b
| * Fix bug when highlight was not respected after currentIndex changedJan Arve Sæther2019-10-081-4/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QQuickListViewPrivate::fixup() seems to only do "fixup" if moveReason != QQuickListViewPrivate::SetIndex By default, moveReason is set to Other. In the snippet given in QTBUG-77418, this is why the highlight was respected when resizing the ListView initially. However, after the currentIndex was changed, moveReason was changed to SetIndex. When we then resized the ListView, it still had the value SetIndex, and would fail to "fixup" properly. Since the ListView preferredHighlightBegin is bound to width, we should set moveReason to Other in the property setters that are related to highlight. This is then consistent with how setCurrentIndex() does it (it similarly sets d->moveReason = QQuickItemViewPrivate::SetIndex;) Change-Id: I7edf77fc977e8c7e3fc656ff5bb22b4dd01afbe4 Task-number: QTBUG-77418 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* | When a DelegateModel delegate changes, refill the viewShawn Rutledge2019-10-091-16/+22
|/ | | | | | | | | | | | | | | | | | It looked a bit odd that the DelegateModel delegate property was not a notifying property. Adding the delegateChanged signal makes it easier to update the view when this happens. The previous approach of removing all delegates and adding all new ones resulted in the view losing its currentIndex and often scrolling to a different place. It's also nice to reduce the number of d-> indirections by adding the QQuickItemViewPrivate::applyDelegateChange() function, so that we just need one indirection to call it, and then it updates all the internal stuff in one place. Done-with: Frederik Gladhorn Done-with: Joni Poikelin Fixes: QTBUG-63477 Change-Id: I2d17fd11ff4a2fcb20968a7182dd2c403abb715a Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* Merge remote-tracking branch 'origin/5.12' into 5.12-merge-5.13Edward Welbourne2019-07-171-0/+3
|\ | | | | | | Change-Id: I9b1cfefda23febfb24282bc30bc38865499ec2f4
| * QQuickItemView: refill itself before populate transitionWang Chuan2019-07-161-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The view uses a visible items list, which is maintained by the refill() method, to determine which items should be triggered to do the populate transition. The refill() was only invoked when component completed before doing the populate transition; but if the size of the view depends on the size of window (for example, using anchors.fill), more delegates could become visible after component completed. In such a case, part of visible items were not be triggered to do the transition. [ChangeLog][QtQuick][Item Views] Item views such as ListView now properly populate delegates with a populate transition when the view is resized after componentComplete. Fixes: QTBUG-76487 Change-Id: Id90c3f73d9911c8a1d6d8b1ea0c51f6c27d0ed5b Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | Merge remote-tracking branch 'origin/5.12' into 5.13Qt Forward Merge Bot2019-06-281-8/+20
|\| | | | | | | Change-Id: I59343fe228ca6b823b61577e5a0907e7381899c2
| * Fix: ListView footer positioned wrong after last item removedEirik Aavitsland2019-06-281-1/+7
| | | | | | | | | | | | | | | | | | | | The refill() method would bail out early on an empty model. Make sure that it at least updates the header and footer in such situations. Fixes: QTBUG-31677 Change-Id: I1f3a1848ff263a8f7f9ccfc3b20f16b61348f57b Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
| * QQuickItemView: fix crash while doing fast flicking in transitionsYulong Bai2019-06-261-7/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | The cause was that fast flicking kicked items in and out of viewport, while in transition, they would abruptly having tracking data structure , i.e. releasePendingTransition of QQuickItemViewPrivate, got iterator invalidated. This also helps to resolve QTBUG-44308. Fixes: QTBUG-76433 Fixes: QTBUG-44308 Change-Id: If14533d3f6b1acd7b6ca0c5c723347c0cb3f54dc Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
* | Merge remote-tracking branch 'origin/5.12' into 5.13Liang Qi2019-06-191-1/+4
|\| | | | | | | | | | | | | | | | | Conflicts: .qmake.conf src/imports/sharedimage/qsharedimageloader.cpp src/quick/items/qquickitemviewfxitem_p_p.h Change-Id: I12ce7c32788f4a394188a934e689b4ebac78138b
| * Fix crash caused by objects self-destructions during displacement animationsYulong Bai2019-06-171-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The root cause was that the QAbstractAnimationJob::finished() might delegate its destruction to change.listener->animationFinished(this), and the original author was aware of that and provided a RETURN_IF_DELETE macro to return early if itself got deleted. In the bug's case, change.listener->animationFinished(this) dispatched to QQuickItemViewPrivate::animationFinished() which called QQuickItemViewPrivate::release() and deleted the QAbstractAnimationJob object itself in the end. However, any objects derived from QAbstractAnimationJob, or holding a pointer to a QAbstractAnimationJob, may potentially fall into the code path calling QAbstractAnimationJob::finished(). Any QAnimationJobChangeListener that directly or indirectly deletes QAbstractAnimationJob should be very suspicious to this kind of "heap-use-after-free" bug. Should ensure that the QAbstractAnimationJob won't be referenced after deletion. In the bug's case, within the code path triggered by ListView displacement animation, the other affected classes by QAbstractAnimationJob are: QQuickItemViewFxItem, QQuickItemViewTransitionableItem, QQuickTransitionManager. To fix this, a new SelfDeletable class is factored out to simplify the self-deletion test logic. Any affected classes are made to have a public member m_selfDeletable. Any code paths that finally reach QAbstractAnimationJob::finished() are wrapped with related util macro. Change-Id: Idd33fc3f2d529fd7d8bb088c329101b1e70dd6c0 Task-number: QTBUG-44308 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* | Fix heap-use-after-free with QQuickListViewAllan Sandfeld Jensen2019-06-041-7/+8
| | | | | | | | | | | | | | | | | | Ensure we stop FXViewItems from tracking so we don't have pointers to dead QQuickListViewPrivate object on QQuickItem destruction. Fixes: QTBUG-71581 Change-Id: I80291086697b1455d9319969fe5cba0ea4d04a73 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* | Add itemAtIndex to quick viewsPaolo Angelelli2019-01-171-0/+7
|/ | | | | | | | | | | | This patch adds itemAtIndex method to ItemView-derived views and to PathView. [ChangeLog][QtQuick][QQuickItemView] Added itemAtIndex() to GridView, ListView and PathView to fetch a visible delegate by index. Change-Id: Id8475d06c1481036984fe5109bb52cf2729b1c21 Fixes: QTBUG-72961 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Item Views: cancel flicking before a model resetTobias Koenig2018-10-191-0/+1
| | | | | | | | | | | While the view is flicking, if the content is updated by a model reset, it gets very confused and creates many delegates that won't be shown inside the visible area. Now we cancel any active flicking before the model reset is handled. Fixes: QTBUG-70742 Change-Id: I6f7aa368b760a00d08c540f3963c32e1e174a908 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Item Views: cancel flicking before programmatic absolute positioningShawn Rutledge2018-10-111-0/+2
| | | | | | | | | | | | When the velocity timeline is driving movement and simultaneously someone calls positionViewAtIndex(), it gets very confused and goes on creating and destroying delegates for a very long time. So now we cancel the flicking animation immediately when calling any of the positionViewAt* invokables. Fixes: QTBUG-70941 Change-Id: I85e09344e79356b877a57ab634f72be1d7f93fca Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* QQuickItemView: Don't change the viewport while in layoutUlf Hermann2018-09-271-0/+6
| | | | | | | | | Moving the viewport in the middle of a layout operation is a bad idea as it causes the visible items to change. Task-number: QTBUG-49224 Change-Id: I45a214560e00b65ed53b9385e7a539bb4304b7d9 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* QQuickItemViewFxItem: factor out FxViewItem from QQuickItemViewRichard Moe Gustavsen2018-03-231-104/+2
| | | | | | | | | | | FxItemViews wraps the QQuickItems used in QQuickItemView with additional item view information, like transition status. This patch will factor out FxItemView so that it can be reused in the coming QQuickTable as well. Change-Id: I5544b177d0ff28b2cbb76f33343808d953ec47bd Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
* use nullptr consistently (clang-tidy)Shawn Rutledge2018-02-261-41/+41
| | | | | | | | | | | | | From now on we prefer nullptr instead of 0 to clarify cases where we are assigning or testing a pointer rather than a numeric zero. Also, replaced cases where 0 was passed as Qt::KeyboardModifiers with Qt::NoModifier (clang-tidy replaced them with nullptr, which waas wrong, so it was just as well to make the tests more readable rather than to revert those lines). Change-Id: I4735d35e4d9f42db5216862ce091429eadc6e65d Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* QQuickItemView::currentItemChanged called upon currentItem destructionAleix Pol2018-02-131-0/+7
| | | | | | | | | There were some cases where the signal wasn't emitted and we ended up with events being delivered to objects that didn't exist anymore. Task-number: QTBUG-65881 Change-Id: I847669a978e82a0332907b029a8295bb993d2850 Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
* Fix transition when removing the last item from ListView/GridViewKari Hautamäki2018-02-021-1/+3
| | | | | | | | | Use the previous item view boundaries (before a remove was applied) when defining transition properties. Task-number: QTBUG-64311 Change-Id: I66870a7267ac26ea430c364383f32fd5c47d4a5d Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QQuickItemView: Clear pending changes when refillingUlf Hermann2017-12-181-35/+41
| | | | | | | | | | | | | | | | | | | | | | | | | Generally the bufferedChanges are an "extension" of the currentChanges, which can just not be applied at the moment because we are in a layout phase. If we regenerate or clear the whole view in the mean time, the bufferedChanges become just as invalid as the currentChanges. On top of that, refilling can trigger further changes, part of which will be applied during the refilling. As that leaves us in an inconsistent state, we need to loop the refilling until no further changes are generated. As the changes might affect items that are already visible, and therefore not subject to refilling, we need to clear all the items before refilling in this case. In QTBUG-46488 things are added in the onCompleted callback of the delegates (by expanding the tree view, which translates into adding rows to the list view). Depending on where you add the new items, the list view might pick them up when iterating the model on refill() or it might create delegates for the same model entry twice. So, if that happens we need to discard the result and refill again. Task-number: QTBUG-46488 Change-Id: Ie4e0a731f7feda6aa962b6cb9a6cd5c3bf90486e Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
* QQmlDelegateModel: add incubationStatus(), and use it to determine ↵Richard Moe Gustavsen2017-11-301-3/+9
| | | | | | | | | | | | | | 'requestedIndex' We used to assign the currently incubating item to 'requestedIndex' based on requested incubation mode alone. This is not sufficient, as the item can also be loaded async when the mode is AsyncIfNested. To check if the item is really loading async (and that we're not getting nullptr because of some other failure), we need to ask the incubator. Task-number: QTBUG-61537 Change-Id: Id1f458db4a7584a6b58d5bad0e7832ce4fc341dc Reviewed-by: J-P Nurmi <jpnurmi@qt.io>
* QQmlIntanceModel: use QQmlIncubator::IncubationMode instead of bool to ↵Richard Moe Gustavsen2017-11-301-5/+5
| | | | | | | | | | | | | | | | | | | | | | specify incubation mode The current implementation would pass a boolean to signal if asynchronous or synchronous incubation should be used to create an item. The problem with this approach is that passing 'synchronous" would translate to QQmlIncubation::AsynchronousIfNested later down the chain. This meant that even if the caller requested synchronous incubation, it could end up with asynchronous incubation anyway, e.g if an async parent incubator was active at the time of the call. And this can easily come as an unhandled supprise for the caller, and as such, cause unforseen bugs. This patch is a first of a set of patches that is done to fix the bug reported in the task below. It will not change any behavior, it is written to preserve the logic exactly as it were, just as a preparation for subsequent patches. It makes it explicit at the call location what incubation mode will be used, and especially make it clear whenever the AsynchronousIfNested flag is in play. Task-number: QTBUG-61537 Change-Id: I8b3ba5438ebb2cd59983a098bd8ceeeb844da87b Reviewed-by: J-P Nurmi <jpnurmi@qt.io>
* Fix ListView::positionViewAtIndex with ListView.Contain modeJoni Poikelin2017-11-071-11/+16
| | | | | | | | | Sticky headers and footers weren't accounted for when calculating new view position causing the requested item to be left behind them. Task-number: QTBUG-63974 Change-Id: Id69579643a942e8558960b2c8b0fee980fa86947 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Fix providing correct velocity when using index based scrollingPasi Petäjäjärvi2017-11-031-3/+0
| | | | | | | | | Index based scrolling does not enable moving and flicking properties. Task-number: QTBUG-34576 Change-Id: Ief06d37115ca389027670c97ce6c0457a74d4872 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QQuickItemView: always honor the removeDisplaced animationAlberto Mardegan2017-11-031-1/+11
| | | | | | | | | | | | | | | The animation was not being performed if the delayRemove attached property was changed by the handler of the remove() attached signal. We need to run the delayed transitions not only if we have an animation for the target item, but also if we have an animation for the items being displaced. (The flag variables can safely be obtained outside of the for loop, given that their value should not change during the loop iteration) Task-number: QTBUG-57225 Change-Id: I8c138677d7dcdf63e0932ec5cf7738c0caeb2ab8 Reviewed-by: J-P Nurmi <jpnurmi@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* ListView: don't stop moving the highlight because of model updatesShawn Rutledge2017-11-031-1/+0
| | | | | | | | | | | | | | | | | In QQuickItemViewPrivate::applyModelChanges(), if moveReason = QQuickItemViewPrivate::Other, then QQuickItemView::trackedPositionChanged() will fail to call d->setPosition(pos), which is normally what keeps the Flickable moving for a while. Leave the reason as-is (it will be SetIndex in this case), so as not to forget that we were actually trying to move down. Updating the model was just a side-effect of that: either because some QML code was trying to append to the model or because fetchMore() was called. Task-number: QTBUG-61269 Task-number: QTBUG-62864 Change-Id: I3fd402469950d6c12e6a8d6e42be83ea4f54776a Reviewed-by: J-P Nurmi <jpnurmi@qt.io>
* QQuickItemView: avoid wrong repositioning of removed itemsAlberto Mardegan2017-11-031-2/+3
| | | | | | | | | | | | | If all the items currently in the view are being removed, lastVisibleIndex will be -1. This caused an unwanted repositioning of all the deleted items, which got moved to a wrong location. Therefore, when all visible items are removed, we should avoid recomputing any item's position. Task-number: QTBUG-57225 Change-Id: I9909748a9cccb5e6a3726306e250921ce69fcba9 Reviewed-by: J-P Nurmi <jpnurmi@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Fix ListView::StrictlyEnforceRange with resizing delegateMichael Brasser2017-08-091-1/+1
| | | | | | | | | | | When fixupPosition is called for a ListView with StrictlyEnforceRange, the original reason for the move is lost, and the fixup is applied immediately. There are already checks for whether the view is moving, so expand these checks to include movement caused by highlight. Change-Id: I25f771b9a529d31dc28acb9f91fcd2b582428200 Task-number: QTBUG-33568 Reviewed-by: Robin Burchell <robin.burchell@crimson.no>
* QQuickItemView: fix releaseItem() loopsJ-P Nurmi2017-06-121-6/+2
| | | | | | | | | | | | | | Calling releaseItem() destroys the item, which emits childrenChanged for the contentItem, and if at that point anything calls setFooMargin(), setContentHeight(), returnToBounds(), or many other methods that indirectly access the visibleItems list, it leads to a crash due to read after free. Add a releaseVisibleItems() helper method that makes a copy, clears the original list first, and then releases the items. Task-number: QTBUG-48394 Task-number: QTBUG-61294 Change-Id: I29e4d3870d33549e8bf789de84c67ab1826fca7d Reviewed-by: Robin Burchell <robin.burchell@crimson.no>
* Run includemocs in qtdeclarativeThiago Macieira2017-04-261-0/+2
| | | | | Change-Id: I84e363d735b443cb9beefffd14b8c023a37aa489 Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* QQuickItemView: use some more C++11 range for loopsJ-P Nurmi2017-01-181-35/+34
| | | | | Change-Id: Ief706dfce0c81351ac06b8791267107ad8165974 Reviewed-by: Robin Burchell <robin.burchell@crimson.no>
* Port existing qmlInfo callers to qmlWarningRobin Burchell2017-01-111-2/+2
| | | | | | | | | | | | | Now that qmlInfo actually reports info messages, we want to change existing callers to use warning-level messages to preserve the original message level. This was done through: perl -p -i -e "s/qmlInfo\(/qmlWarning\(/" **/*.{cpp,h,qdoc} .. with a little care taken to only add the hunks that should be changed. Change-Id: I511cee11ce0a26ec1048cd2b84c7536b812a0d89 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-03 15:23:44 +0000