aboutsummaryrefslogtreecommitdiffstats
path: root/src/quick/items/qquicklistview.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Merge remote-tracking branch 'origin/tqtc/lts-5.15.4' into ↵v5.15.4-lts-lgplTarja Sundqvist2022-04-071-9/+93
|\ | | | | | | | | | | tqtc/lts-5.15-opensource Change-Id: I39595f8b7ad212c842709b939226d95531819391
| * DelegateModelGroup: Fix bug where item could be removed from the modelJan Arve Sæther2021-03-301-9/+93
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If an item was removed from the DelegateModelGroup before it was completed it caused subsequent items in the model to be missing in some cases. The reason was that while populating the ListView, it iterated with an index for each item to call createItem() on. However, createItem() might call onCompleted (which in the case of QTBUG-86708 removed the item from the DelegateModel), which caused the next index we called createItem() with to be wrong (it became one step ahead). We therefore add a helper class MutableModelIterator, which keeps track of if a index in the model got removed (and if the iterator index needs to be adjusted because of that).... Task-number: QTBUG-86708 Change-Id: I33537b43727aed4f2b9bdda794b011b6684c44b4 Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io> (cherry picked from commit 0ff9db566c48172c688bf9327fe6a781dc4a1c34) Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
* | Revert "Update commercial license headers"v5.15.3-lts-lgplTarja Sundqvist2021-03-241-20/+20
|/ | | | | | | | | | | This reverts commit 7b1331c789df0ac12d7cf5aa5f8967b8651a4cfa. Revert of commercial license headers is required for Qt 5.15.3 opensource release. Task-number: QTBUG-91108 Change-Id: I47eb004523bdb3beb16e9fd51e40da6f738f9f34 Reviewed-by: Jukka Jokiniva <jukka.jokiniva@qt.io>
* Update commercial license headersTarja Sundqvist2021-02-021-20/+20
| | | | | | | | | | | | | | | Updated header.COMM to the files in tqtc-qtdeclarative. Examples, documentation files or tests are not updated. The commercial license header may contain some additional lines so that its line count equals with the earlier license header. Reason for this is that some autotests use hard coded line numbers and a change in the line count causes failures in tests. Task-number: QTQAINFRA-4161 Change-Id: Ic1d011aa01b1fe7242bcbbf72d5ab454d1015cf9 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* QQuickListView: prevent mouse delivery in floating header or footerShawn Rutledge2020-10-071-9/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | Earlier we reimplemented the contains() method of ListView to prevent dragging in an Overlay or Pullback header or footer. But in QQuickWindow (QQuickWindowPrivate::pointerTargets()), an early check prevents delivery of pointer events to an item that is clipped and for which contains() returns false, and also to its children. In that case, the header or footer no longer responds to a mouse event even if you put a MouseArea in it. Reverts 6ad3445f1e159d9beea936b66d267dcaacdc5d6c; reimplemented using similar logic in a new QQuickListViewPrivate::wantsPointerEvent() method, overriding QQuickFlickablePrivate::wantsPointerEvent(), which is now checked in event-handling code in addition to checking the interactive flag. Done-with: Wang Chuan <ouchuanm@outlook.com> Task-number: QTBUG-74046 Fixes: QTBUG-85302 Change-Id: I9474f035d26b74ee36c0ac19e45a77de2e694bf1 Reviewed-by: Wang Chuan <ouchuanm@outlook.com> Reviewed-by: Mitch Curtis <mitch.curtis@qt.io> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io> (cherry picked from commit 6857ad3e686a5e2b45d28a7f47dca3210608da50) Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* doc, listview: document that binding to parent should be avoidedRichard Moe Gustavsen2020-08-201-2/+24
| | | | | | | | | | | | | | | | | | | | | | | Clearify in the documentation that the parent of a delegate can change during its lifetime, and even be null. And because of that, they should avoid binding to it. In general, how a control is structured internally should be understood as a private implementation detail. Even if the application has the freedom to read (and even change) the internal parent-child hierarchy as it sees fit, doing so can be fragile as the internal structure of a control can easily change from one version to the other. [ChangeLog][QtQuick][ListView] Since the parent of a delegate can end up being null during its lifetime, developers are now advised against using it in bindings. Fixes: QTBUG-82989 Change-Id: I2d6c79102435d0969f4dc3deec13c5fff4affeb1 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io> (cherry picked from commit ed73efa27acd8e7c42a960ef90c2e4a898c20c30) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Doc: fix typo in ListView::layoutDirectionMitch Curtis2020-05-191-1/+1
| | | | | | | Change-Id: I04e1e2ab145aa93952d2dd5ec34321ad87c8af9e Reviewed-by: Paul Wicking <paul.wicking@qt.io> (cherry picked from commit 0e393fa01fd86e7ffeb35f25c9644f47d99d811a) Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* Remove hard-coded notes for 'Corresponding handler' for QML signalsTopi Reinio2020-03-101-4/+0
| | | | | | | | QDoc will generate these notes automatically. Task-number: QTBUG-37355 Change-Id: I8ed058ecbbcc630ad0351f6ce167c3fa61936f6f Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* Merge remote-tracking branch 'origin/5.14' into 5.15Qt Forward Merge Bot2020-02-061-15/+153
|\ | | | | | | | | | | | | | | | | | | Conflicts: .qmake.conf src/qml/types/qqmlbind.cpp src/quick/items/qquicklistview.cpp tests/auto/qml/qqmllanguage/tst_qqmllanguage.cpp Change-Id: Id6805c13256ad13d5651011e5dd09bba0ec02987
| * Fix some ListView bugs related to snapping when it had a headerJan Arve Sæther2020-01-301-15/+153
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Most bugs were related to the PullBackHeader header positining mode, for instance the old code did not take into consideration that for the PullBackHeader it was sometimes not sufficient to scroll the view. The header also had to be scrolled independently from the view: We achieve this by hooking on to the same timeline that is used for scrolling the view. (This way, both animations are synchronized, and they start and end at the same time). Change-Id: I75708c0fd8d4741032c04ad9ee144d7a49cf3359 Fixes: QTBUG-76362 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | Improve ListView.headerPositioning docsShawn Rutledge2019-12-231-12/+20
| | | | | | | | | | | | | | | | Explain the changes to fix QTBUG-74046 and improve grammar. Task-number: QTBUG-74046 Change-Id: Icd02387a2ffb3ff795521cb5eda95e41eabc21c7 Reviewed-by: Venugopal Shivashankar <Venugopal.Shivashankar@qt.io>
* | QQuickListView: document delegate item recyclingRichard Moe Gustavsen2019-12-091-0/+47
| | | | | | | | | | Change-Id: I6777eb179643ca2d5fb14f96f5f5ac02f5f2fb04 Reviewed-by: Venugopal Shivashankar <Venugopal.Shivashankar@qt.io>
* | Don't allow dragging a ListView through a floating header or footerShawn Rutledge2019-12-041-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the header or footer positioning is Overlay or PullBack, the list delegates appear to scroll underneath it. The header or footer can contain interactive content. If a mouse or touch press happens to "fall through" that, it should not be possible to drag the ListView contents from there. [ChangeLog][QtQuick][ListView] ListView no longer allows the user to press on an Overlay or PullBack header or footer and start scrolling, but only on the content delegates. Fixes: QTBUG-74046 Change-Id: I4d06c789286be2691d098aeebb10a57b2a335744 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* | QQuickListView: implement support for reusing itemsRichard Moe Gustavsen2019-12-041-6/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge remote-tracking branch 'origin/5.14' into 5.15Liang Qi2019-11-221-1/+2
|\| | | | | | | | | | | | | | | Conflicts: src/qml/qml/qqmlextensionplugin.cpp tests/auto/quick/qquicktableview/tst_qquicktableview.cpp Change-Id: Ic58d36a8532015bae30f2690063db9829b3bf372
| * Merge remote-tracking branch 'origin/5.13' into 5.14Qt Forward Merge Bot2019-11-141-0/+1
| |\ | | | | | | | | | Change-Id: I06578422b4558feabf7a77426b01e77953ab60e2
| | * Fix a layout bug caused by a delegate item that was moved by the user5.13Jan Arve Sæther2019-11-121-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | Doc: Fix documentation warningsTopi Reinio2019-11-111-1/+1
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There were a lot of documentation warnings introduced by the separation of QtQml.Models and QtQml.WorkerScript modules from the QtQml documentation project into their own sub-projects. Fix the above, and also ensure that the experimental Qt.labs.qmlmodels QML types are listed in the documentation, and add them also on the QML module page for QtQml.Models. A few warnings remain, they may be indicative of issues not in the scope of this commit. Fixes: QTBUG-79812 Change-Id: Idc25c976e4c96feab4aae893519d6c9245f57a64 Reviewed-by: Paul Wicking <paul.wicking@qt.io>
* | Merge remote-tracking branch 'origin/5.14' into 5.15Qt Forward Merge Bot2019-10-041-1/+22
|\| | | | | | | | | | | | | | | Conflicts: src/imports/qtquick2/plugins.qmltypes src/quick/items/qquickitemsmodule.cpp Change-Id: I841c65c9c131354788b4f3fcfe3d7ed27be316d5
| * Merge remote-tracking branch 'origin/5.12' into 5.13Qt Forward Merge Bot2019-08-281-1/+22
| |\ | | | | | | | | | Change-Id: I0ae0a162e133cffd8fb1a2c6b70826e50f06facd
| | * doc: Clarify that the delegate populate transition doesn't always runShawn Rutledge2019-08-121-1/+22
| | | | | | | | | | | | | | | | | | Fixes: QTBUG-42798 Change-Id: If10f06450f1e50893e5ba103e7c8c2d83667a651 Reviewed-by: Venugopal Shivashankar <Venugopal.Shivashankar@qt.io>
* | | qquicklistview: support required properties in sectionDelegateFabian Kosmale2019-09-121-6/+23
|/ / | | | | | | | | | | | | | | | | | | This changes the accessibile properties in the sectionDelegate: If the sectionDelegate contains requiredProperties, "section" will not be injected into a newly created parent scope. Instead, the section property of the delegate will be set if it exists. Change-Id: I34b04d08d2f80af7ea53fd722f08be0f9aea6e72 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* | Fix heap-use-after-free with QQuickListViewAllan Sandfeld Jensen2019-06-041-7/+10
| | | | | | | | | | | | | | | | | | 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>
* | Merge remote-tracking branch 'origin/5.12' into 5.13Qt Forward Merge Bot2019-02-141-0/+5
|\| | | | | | | Change-Id: I2842f4a8096c4555e29f08e65b88b77b841441cb
| * Doc: explain when the move velocity and duration properties are usedMitch Curtis2019-02-071-0/+5
| | | | | | | | | | Change-Id: Iaf7cf035f76a1f198c60f4792d394b0fd19ef901 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | Add itemAtIndex to quick viewsPaolo Angelelli2019-01-171-0/+14
|/ | | | | | | | | | | | 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>
* Doc: velocity properties must be set to -1 when setting durationMitch Curtis2018-12-131-1/+12
| | | | | | | | | This is an important detail that was left out, causing confusion when a user tries to set e.g. highlightMoveDuration without setting highlightMoveVelocity to -1. Change-Id: Ida4042626fcc20105267a5d2a0babcb91eed1516 Reviewed-by: Michael Brasser <michael.brasser@live.com>
* Improve interaction between snapping and sectionsMichael Brasser2018-10-171-11/+27
| | | | | | | | | | * Use velocity to prefer snapping in the active direction. * Calculate snap based on where the item is, rather than where the section is. Change-Id: I2531501dbe0a58f26f20bc3e719e435185e047a5 Task-number: QTBUG-67051 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* Doc: Remove documentation for deprecated QML typesVenugopal Shivashankar2018-09-251-1/+1
| | | | | | | | | | | | | VisualDataModel, VisualDataGroup, and VisualItemModel are replaced with DelegateModel, DelegateModelGroup, and ObjectModel respectively (since 7cad0e52c5a020bd29635e9912fd8946a6b48124). Also renamed/deleted a few snippet files and an image. Task-number: QTBUG-37725 Change-Id: I5fa93993a31d8f9b08e7a282d5550ddd9bfb813f Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Expand docs on SnapOneItemMichael Brasser2018-07-191-1/+5
| | | | | | Change-Id: Ia8b96edd49467c2c54ef4e1a0332a94c9a3986a9 Reviewed-by: Albert Astals Cid <aacid@kde.org> Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* StrictlyEnforceRange should not override valid SnapOne decisionsMichael Brasser2018-06-291-2/+2
| | | | | | | | | | The changes made in 134d980a7fcf61c5440019bcfb3fdfc39c3f5f3c and 2b779fbd25aaf09897ee2cdc4edffd12a980420b were still a bit too broad. Tighten the condition further so original behavior is restored for smaller to medium drags. Change-Id: I9006e9cea80c1ef79e0b8d6a47b2a497532bef57 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* Fix SnapOneItem/Row behavior for mid-range flicksMichael Brasser2018-06-291-3/+3
| | | | | | | | | | Previously small and large flicks would go to the next item, but there was a small range just under halfway where it would snap to the previous position (most easily hit with smaller delegates). Get rid of this blindspot. Change-Id: Ib8d026cad9427b2d209a9646b3ea515f578457ae Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* Doc: Add missing dots (qtdeclarative)Paul Wicking2018-06-191-1/+1
| | | | | | Task-number: QTBUG-68933 Change-Id: Ibb5aa227e82825085e7214e17dcffcb17fd44157 Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
* Fix QQuickListViewPrivate::snapItemAt for lists with spacingJohan Klokkhammer Helsing2018-04-251-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If lists had spacing, snapping would have gaps where snapItemAt would return nullptr eventhough there were items above and below in the list. I.e. if we have a list with items of size 100, and a spacing of 100, and scroll to 110 (right below the first item), then the first item would fail because this is false: itemTop+itemSize()/2 >= pos (50 >= 110) And the next item (the one we should have snapped to), would fail because this is false: itemTop-prevItemSize/2 < pos (200-100/2 < 110) The meaning of first part was probably to see if the middle of the current item is inside the view. The meaning of the second part was probably to see if the middle of the previous item is outside the view. This patch refactors the code so it's more visible what's happening and fixes the bug by taking the spacing into account when computing the position of the halfway positions. Task-number: QTBUG-59852 Change-Id: I60eec0d16e91d2f22d70b97d11bcde5d88ac2997 Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* use nullptr consistently (clang-tidy)Shawn Rutledge2018-02-261-32/+32
| | | | | | | | | | | | | 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>
* QQuickList/GridViewPrivate::fixupPosition: don't set moveReasonShawn Rutledge2017-12-161-3/+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 when the sequence window->polishItems() -> QQIV::updatePolish() -> layout() -> fixupPosition() did its part of the work of moving down. Task-number: QTBUG-62864 Change-Id: I1021e2ea39265de9e1285e2ee17c5733189ab939 Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QQuickListView/GridView: load items that results from model changes ↵Richard Moe Gustavsen2017-11-301-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | synchronously The current implementation created new items with default incubation mode, which is AsynchronousIfNested. But from reading the code, it seems like changes to the model were really expected to be handled synchronously, since there aren't any sections in the code that will recover from situations were requested items ends up incubating async. This is also backed by the fact that the second argument used to be a bool set to 'synchronous'. The fact that this was translated to AsynchronousIfNested later down the chain didn't seems to be taken into account. A bug with this is found in ListView when it's embedded inside an async Loader. In that case, all list items will be incubating async at startup, which is normally expected and fine. But if the model assigned to the ListView is modified before the loader has finished, async loading will also happen to the items created because of the change. And then the situation described above will occur. This patch will force any items loaded because of a model change to be synchronous. This seems to be in line with the synchronous logic that already exists. And its also quite acceptable, since changing the model before everything is completed is a corner case, and can naturally lead to some stuttering in the list view anyway. A potential for improvement on this logic is to try to recover whenever creating an item fails. But this takes a lot of work because of the way model changes are structured and stored, and can easily cause regressions. Since this is a corner case, it is probably not worth it. [ChangeLog][QtQml][ListView] Fixed a bug in ListView that sometimes make items end up with wrong geometry when changes to its model happens while the ListView is being loaded async (e.g if wrapped inside an async Loader). Task-number: QTBUG-61537 Change-Id: I8d6857beaf8ef98b02bb46282a1312749b0fb801 Reviewed-by: J-P Nurmi <jpnurmi@qt.io>
* QQmlIntanceModel: use QQmlIncubator::IncubationMode instead of bool to ↵Richard Moe Gustavsen2017-11-301-2/+4
| | | | | | | | | | | | | | | | | | | | | | 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>
* QQuickListView: ensure we re-layout when a delegate is placed at the last ↵Richard Moe Gustavsen2017-08-301-6/+4
| | | | | | | | | | | | | | | | | | | | | | visible pos The current implementation would only return true if the added delegate was positioned below the last visible pixel. This caused a problem when the position ended up at exactly the last visible position, since then we would return false, meaning that a re-layout would not be done. Since we use the same calculations several places, this patch will factor it out into lastVisiblePos, and also fix up the places where we test on it. Especially this includes making sure that we set visibleAffected to true if we actually enter the for-loop that adds the item to visibleItems. To make the code more readable (and to ensure that we are consistent), we set it to true inside the for-loop. Task-number: QTBUG-61537 Change-Id: Ie697b5b6d9f4236ee856bde75fd9bc0a07dda7ea Reviewed-by: J-P Nurmi <jpnurmi@qt.io>
* Fix ListView::StrictlyEnforceRange with resizing delegateMichael Brasser2017-08-091-0/+12
| | | | | | | | | | | 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>
* Doc: explain ListView default Z values in detailMitch Curtis2017-07-061-7/+55
| | | | | | | | | | | This should save users some time when they are trying to figure out why the delegate items are rendered underneath the header when headerPositioning is set to ListView.OverlayHeader, for example. Task-number: QTBUG-61346 Change-Id: I490250f2a64a8bbda463b3a31be6f820d0cfe881 Reviewed-by: J-P Nurmi <jpnurmi@qt.io> Reviewed-by: Robin Burchell <robin.burchell@crimson.no>
* QQuickItemView: fix releaseItem() loopsJ-P Nurmi2017-06-121-3/+1
| | | | | | | | | | | | | | 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>
* Item views: Q_DECL_OVERRIDE -> overrideJ-P Nurmi2017-01-181-47/+47
| | | | | | Change-Id: I7dfbd5f47893a3244c96989ad7eea7e93ea28603 Reviewed-by: Robin Burchell <robin.burchell@crimson.no> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* QQuickListView: use C++11 range for loops for visible itemsJ-P Nurmi2017-01-171-16/+11
| | | | | Change-Id: I0e60c54281cf6838845400fe1a7cf5f2b3a14d65 Reviewed-by: Robin Burchell <robin.burchell@crimson.no>
* Item views: eliminate some repeated QList::at() accessJ-P Nurmi2017-01-161-15/+24
| | | | | Change-Id: Iccc1ec0cf4408e25c04ca0be2562175e76d2d198 Reviewed-by: Robin Burchell <robin.burchell@crimson.no>
* ListView: allow flicking to both directionsJ-P Nurmi2017-01-161-6/+48
| | | | | | | | | | | | | | | | Previously flicking was restricted to the orientation of the ListView. [ChangeLog][QtQuick][ListView] Made it possible to enable horizontal flicking in a vertical ListView, and vice versa. The only thing apps must do is to specify the desired flick direction and the content width (vertical ListView) or content height (horizontal ListView), which is not calculated by ListView. Change-Id: Ic370e57f5d18679940d48e7a2c20c200b2ef36d1 Task-number: QTBUG-52553 Task-number: QTBUG-56501 Reviewed-by: Robin Burchell <robin.burchell@crimson.no> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Quick: Do not calculate the difference in a geometryChangeErik Verbruggen2016-11-101-11/+9
| | | | | | | | | | | This difference is only used by the ListView, so calculating it and storing it (on the stack) introduces a penalty for all items. As the new geometry is already applied, the old geometry is passed along. This has the added advantage that the ListView does not have to re-calculate that either. This fixes a performance regression. Change-Id: Id5e67bb663a5b11a55ec15ff24ca5b213d1fcef5 Reviewed-by: Gunnar Sletta <gunnar@sletta.org>
* Merge remote-tracking branch 'origin/5.6' into 5.8Simon Hausmann2016-10-131-1/+1
|\ | | | | | | Change-Id: I175b27337b534c0b8f46a4a792d2c43cde73ffc4
| * QQListView: use dot for property syntaxFrederik Schwarzer2016-10-061-1/+1
| | | | | | | | | | | | | | Additionally, that way the braces are not needed anymore. Change-Id: I5afc8fa738211f884ac011079a2ee63613a46d08 Reviewed-by: Venugopal Shivashankar <Venugopal.Shivashankar@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-20 13:03:13 +0000