aboutsummaryrefslogtreecommitdiffstats
path: root/src/quick/items/qquicklistview.cpp
Commit message (Collapse)AuthorAgeFilesLines
* 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>
* | Merge remote-tracking branch 'origin/5.7' into devLiang Qi2016-08-191-2/+2
|\ \ | | | | | | | | | Change-Id: I326616356ee26d4532c6d57558c43c919f0a900d
| * | Merge remote-tracking branch 'origin/5.6' into 5.7Liang Qi2016-08-191-2/+2
| |\| | | | | | | | | | Change-Id: I7bd70996e3372d154c6b0e47336baa22146667b0
| | * QQuickListView: fix doc for itemAt() and indexAt()Anton Kudryavtsev2016-08-181-2/+2
| | | | | | | | | | | | | | | | | | | | | These methods have real arguments. Change-Id: Ieb4ea8396876f237adedf5df8ab5aeec1055229f Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* | | Quick: use const (and const APIs) moreAnton Kudryavtsev2016-08-121-12/+12
| | | | | | | | | | | | | | | | | | | | | | | | For CoW types, prefer const methods to avoid needless detach()ing. Change-Id: I270cdc6eb8c5946f5c20b379bbb7c60f0ba518eb Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io> Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* | | Fix regression after geometry change refactoringAllan Sandfeld Jensen2016-07-121-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit e2c296c46b3f922ed12f83b166b1493dfded480e removed the passing of the original geometry to the itemGeometryChanged method, and had a wrong calculation of the original value the one place it is still needed. Change-Id: I69fdd89c2643b4b5d6a3483f961cf5f1de4d2dbf Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
* | | QML: Pass the kind of geometry change aroundErik Verbruggen2016-07-111-11/+15
|/ / | | | | | | | | | | | | | | | | | | | | | | | | This prevents re-calculation of what actually changed, and removes the now unused parameter newGeometry. Other than this change calculation, the only place where oldGeometry was used is QQuickListViewPrivate::itemGeometryChanged. To get rid of oldGeometry too, QQuickListViewPrivate now stores the current (i.e. last known) geometry, and updates it in itemGeometryChanged. Change-Id: I8a5286d08a04132c9a4c81de7ce221f5676946e6 Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io> Reviewed-by: Robin Burchell <robin.burchell@viroteck.net>
* | Merge remote-tracking branch 'origin/5.6' into 5.7Liang Qi2016-06-291-2/+6
|\| | | | | | | Change-Id: I70c0c672708522f7157849365cc53ee271d8e460
| * Report changes correctly when inserting into a ListViewStephen Kelly2016-06-211-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit v5.6.0-beta1~7 (ListView: Sanitize visibleItems list after model insertions, 2015-12-07) introduced sanitizing of the container of visibleItems, but it did not affect the return value of the QQuickListViewPrivate::applyInsertionChange function. The return value is used in QQuickItemViewPrivate::layout() to determine whether the layouting should proceed, or an early return is possible instead. If the layouting does not proceed, then the newly inserted visible items do not get painted, resulting in the linked bug. The return value of the QQuickListViewPrivate::applyInsertionChange function was previously determined by whether the new count of visible items is greater than the previous count. After the sanitation in commit v5.6.0-beta1~7, this numeric comparison is no longer a good indicator of whether a repaint is needed. Change the return value to indicate whether new items were inserted which are visible in a more-direct way. Verify that visible items are initialized correctly in tests. They should not be 'culled'. It is necessary to invoke the layout method first to clear the forceLayout state. Two pre-existing tests fail before the fix in this patch. Change-Id: I625f1e02bf7001834adb147161a1e478a0ce2a0d Task-number: QTBUG-53263 Reviewed-by: Robin Burchell <robin.burchell@viroteck.net>
* | Merge remote-tracking branch 'origin/5.6' into 5.7Liang Qi2016-06-201-4/+6
|\| | | | | | | | | | | | | | | Conflicts: src/qml/jit/qv4targetplatform_p.h src/quick/accessible/qaccessiblequickitem_p.h Change-Id: Ic95075a5fad81ec997a61561bd65979dfa3b9d4d
| * ItemViews: Make the wording of the warning on cache properties slightly sterner.Robin Burchell2016-06-161-4/+6
| | | | | | | | | | | | | | | | | | I have seen far too many cases of someone simply setting cacheBuffer to a massive number in an attempt to workaround a slow delegate. It should be explicit that cacheBuffer is not a solution for these problems. Change-Id: I09416d06ff7faf51a104e09ca5f6b3593ddc53c7 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* | Doc: Fix incorrect 'See also' referencesTopi Reinio2016-02-171-1/+1
| | | | | | | | | | | | | | | | | | | | Fixes these documentation warnings: src/quick/items/qquickgridview.cpp:1512: warning: Can't link to 'l' src/quick/items/qquicklistview.cpp:2183: warning: Can't link to 'l' Change-Id: Icbe4715f12cd66742873c815ef2ffc29b96b36fb Reviewed-by: Mitch Curtis <mitch.curtis@theqtcompany.com>
* | Merge remote-tracking branch 'origin/5.6' into devSimon Hausmann2016-01-221-2/+2
|\| | | | | | | Change-Id: I4af0bf8ec1569097d97f8ce0bb8bf1a0e4a989ec
| * QQuickItemView: Take sticky header/footer into account for ↵Robin Burchell2016-01-151-2/+2
| | | | | | | | | | | | | | | | | | | | | | positionViewAtIndex(). When using an overlaid header or footer, we must adjust the position we come up with by the appropriate size in order to end up at the correct place. Change-Id: I218b9aef7fdf37f56ffb63dc395f97045b55a186 Task-number: QTBUG-50097 Reviewed-by: J-P Nurmi <jpnurmi@theqtcompany.com>
* | Updated license headersJani Heikkinen2016-01-191-14/+20
| | | | | | | | | | | | | | | | | | | | | | From Qt 5.7 -> LGPL v2.1 isn't an option anymore, see http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/ Updated license headers to use new LGPL header instead of LGPL21 one (in those files which will be under LGPL v3) Change-Id: Ic36f1a0a1436fe6ac6eeca8c2375a79857e9cb12 Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
* | Merge remote-tracking branch 'origin/5.6' into devLiang Qi2015-12-181-11/+48
|\| | | | | | | | | | | | | Conflicts: tests/auto/quick/qquicklistview/tst_qquicklistview.cpp Change-Id: I9588a3e2c7d590e031dd4c66905a79f0d74d3ac8
| * ListView: Sanitize visibleItems list after model insertionsGabriel de Dietrich2015-12-071-11/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In QQuickListViewPrivate::applyInsertionChange(), we update the visibleItems list by first shifting the currently visible items and then we add as many items as the model was added and at the right position. We do this in such a way that we won't create items that will not be visible right away (and may be deleted right after by removeNonVisibleItems()). However, this may leave gaps in the item index sequence, and QQuickListView doesn't always recover gracefully from it. The purpose of this patch is to make sure those gaps are cleared right after inserting the new items. Since the insertions can happen in two different places (either before or after the first visible item) we need to update the visibleItems list accordingly. The way we sanitize visibleItems is by removing those items that lie beyond a possible index gap. If insertion happens before the first visible item, we'll remove all those items before the insertion point. If the insertion happens after the first visible item, we'll remove the items after the insertion point. Besides that, the logic for inserting before the visible position was wrong. As items are inserted bottom-up in that case, the insertion would start by just accounting for the item's size until the condition pos > from && insertionIdx < visibleIndex would become false only because 'pos' would be small enough. After that, the next loop run would start adding items before the 'from' position, which is wrong. Our fix is to move the condition outside the loop if the insertion index will be before the visible index and just account for the items' size in that case. Otherwise, the insertion happens as usual until pos < from. Change-Id: I35767cf6e9737bea1fe7677e580245fc7172710c Task-number: QTBUG-48870 Reviewed-by: Shawn Rutledge <shawn.rutledge@theqtcompany.com> Reviewed-by: Robin Burchell <robin.burchell@viroteck.net>
* | ListView: add keyNavigationEnabled propertyMitch Curtis2015-12-081-1/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | It is useful for applications that need to selectively enable or disable mouse and keyboard interaction. [ChangeLog][QtQuick][ListView] added keyNavigationEnabled property to allow mouse and keyboard interaction to be selectively enabled/disabled. Change-Id: I1cdb73e7be105bcc5c131e3cf2ae242dc66e8a65 Task-number: QTBUG-17051 Reviewed-by: J-P Nurmi <jpnurmi@theqtcompany.com>
* | Merge remote-tracking branch 'origin/5.6' into devLiang Qi2015-12-071-16/+18
|\| | | | | | | Change-Id: Ica75a71062d0613e415f2433c5c22c2e251b37cd
| * QQuickListView: Refactor FxViewItem releasing codeGabriel de Dietrich2015-12-011-14/+16
| | | | | | | | | | Change-Id: Id13e982ff3286ec6f369c3d5898de3da3314579d Reviewed-by: Shawn Rutledge <shawn.rutledge@theqtcompany.com>
| * ListView: fix random crashes when accessing deleted objectsJ-P Nurmi2015-11-261-2/+2
| | | | | | | | | | | | | | | | | | | | These crashes occur randomly with tst_combobox from qtquickcontrols2, and with the test case attached to the linked bug report. Change-Id: If7d91045f86ec33e7fe398ed02f3edf80700651a Task-number: QTBUG-48277 Reviewed-by: Nikita Krupenko <krnekit@gmail.com> Reviewed-by: Liang Qi <liang.qi@theqtcompany.com>
* | Merge remote-tracking branch 'origin/5.6' into devLiang Qi2015-11-211-2/+2
|\| | | | | | | Change-Id: I3567f741394f912d4312460e85555b6c39b61cb4
| * Don't make currentIndex skip an extra item on removalAlberto Mardegan2015-11-131-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | Improve the logic for determining the desired viewport position, which got partially broken with 134d980a7fcf61c5440019bcfb3fdfc39c3f5f3c. Let's not alter topItem and bottomItem if their index appears to be correct. Task-number: QTBUG-49330 Change-Id: Ib1c88de51be28cbb0afb1741440adb03ae8ebd87 Reviewed-by: Albert Astals Cid <albert.astals@canonical.com> Reviewed-by: J-P Nurmi <jpnurmi@theqtcompany.com>
* | QQuickListView: Make sticky headers & footers work with no list items.Robin Burchell2015-09-281-9/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Overlay headers are supposed to be fixed in position. This worked for "usual" cases, but flicking a list with an empty model allowed the header & footer to move. Two fixes were required: * viewportMoved needs to call updateHeader and updateFooter if there are no items if sticky headers are enabled * updateHeader and updatefooter need to always fix the position of the header & footer. Change-Id: I77519d91f587458777c6c8f4863270cf762ac286 Reviewed-by: J-P Nurmi <jpnurmi@theqtcompany.com>
* | QQuickListViewPrivate::updateHeader: Remove unnecessary nullptr check.Robin Burchell2015-09-281-16/+14
|/ | | | | | | | | | updateHeader checks for a nonexistent header at the very beginning and creates one if there is none, so 'header' will always have a valid pointer. static_cast isn't type-safe, so if it wasn't a FxListItemSG, it wouldn't end up giving us 0 anyway, so this check did nothing. Change-Id: I7a021173b2ab7c634f0a290b8e3b3e1659756076 Reviewed-by: J-P Nurmi <jpnurmi@theqtcompany.com>
* ListView: Set currentItem's culled state on geometry changeGabriel de Dietrich2015-09-211-0/+9
| | | | | | | | | | | | | | | When the viewport is moved, the ListView may cull its currentItem if it's out of the viewport bounds. However, it could be that this is only a transient state while the currentItem is being animated. Unfortunately, we don't uncull the currentItem at any moment during the animation. To solve this, we simply set the currentItem's culled state every time its geometry changes. Change-Id: I72d548f13f229029ccd8568721ea23e73f7b4392 Task-number: QTBUG-48044 Reviewed-by: J-P Nurmi <jpnurmi@theqtcompany.com>
* Merge remote-tracking branch 'origin/5.5' into 5.6Ulf Hermann2015-08-181-4/+4
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/qml/debugger/qv4debugservice.cpp src/qml/jsruntime/qv4value_inl_p.h src/qml/jsruntime/qv4value_p.h src/qml/memory/qv4mm.cpp src/qml/memory/qv4mm_p.h src/qml/qml/qqmlnotifier_p.h src/qml/qml/qqmlproperty.cpp src/quick/items/qquickflickable.cpp src/quick/items/qquicktextedit.cpp tests/auto/quick/qquickwindow/BLACKLIST The extra changes in qqmlbinding.cpp are ported from changes to qqmlproperty.cpp that occurred in parallel with writeBinding() being moved to qqmlbinding.cpp. Change-Id: I16d1920abf448c29a01822256f52153651a56356
| * Consistently use the override keywordThiago Macieira2015-07-191-4/+4
| | | | | | | | | | | | | | Clang doesn't like when it's inconsistent. Change-Id: Ib306f8f647014b399b87ffff13f23eebda07757b Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
* | Don't change the currentItem after a viewport resizeAlberto Mardegan2015-07-201-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When highlightRangeMode is set to StrictlyEnforceRange and the view gets resized, we don't want the currentIndex to change. The code touched by this patch was introduced by commit I08b7e61496a79f71c3b40fafaca985ae90f88503 back in Qt 4.7 times, and never changed since then. Task-number: QTBUG-43555 Change-Id: Ie67faa6898f13a1f7b0f1c4ae6c29721cb7dfa41 Reviewed-by: J-P Nurmi <jpnurmi@theqtcompany.com> Reviewed-by: Michael Brasser <michael.brasser@live.com> Reviewed-by: Alan Alpert <aalpert@blackberry.com>
* | Fix QQuickListViewPrivate::releaseItem()J-P Nurmi2015-07-101-1/+2
| | | | | | | | | | | | | | | | | | Fixes a regression introduced by 1e3924d. The FxViewItem gets deleted by QQuickItemViewPrivate::releaseItem(), so the QQuickItem pointer must be stored before calling the base class implementation. Change-Id: I0bcffc7bee8a4cdbebdce0fe2d2b990bfa52dc6c Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
* | Merge remote-tracking branch 'origin/5.5' into devLiang Qi2015-06-301-13/+17
|\| | | | | | | | | | | | | | | | | | | Conflicts: .qmake.conf src/qml/qml/qqmlengine.cpp src/quick/items/qquickitemsmodule.cpp tools/qml/main.cpp Change-Id: Ida8daf6b4d7e675385f2f5514c446e52dedaf136
| * Correctly initialize ListView section attached properties.Martin Jones2015-06-251-13/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During item insertion, indexes of items in the visibleItems list were not adjusted before new items were created. Section initialization was broken during insertion because section calculation relies on the indexes of the items in the visibleItems list. The incorrect section properties caused spurious section header creation, and layout issues. Apply the index offset before creating the new items. This mirrors what GridView already does. Change-Id: I549a81825cf0e979bc5830840bf6cb75c7a82cac Task-number: QTBUG-43873 Reviewed-by: Bea Lam <bea.lam@jollamobile.com>
* | ListView: more robust output in debug messageLiang Qi2015-06-291-5/+5
| | | | | | | | | | | | | | | | Contains essentially the same information, but allows the item pointer to be null. Change-Id: Ib848e0050c895facfbf13bddc6fec12df37a66ff Reviewed-by: J-P Nurmi <jpnurmi@theqtcompany.com>