| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
| |
Change-Id: I84e363d735b443cb9beefffd14b8c023a37aa489
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
| |
Change-Id: I7dfbd5f47893a3244c96989ad7eea7e93ea28603
Reviewed-by: Robin Burchell <robin.burchell@crimson.no>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
| |
Change-Id: I0e60c54281cf6838845400fe1a7cf5f2b3a14d65
Reviewed-by: Robin Burchell <robin.burchell@crimson.no>
|
|
|
|
|
| |
Change-Id: Iccc1ec0cf4408e25c04ca0be2562175e76d2d198
Reviewed-by: Robin Burchell <robin.burchell@crimson.no>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|\
| |
| |
| | |
Change-Id: I175b27337b534c0b8f46a4a792d2c43cde73ffc4
|
| |
| |
| |
| |
| |
| |
| | |
Additionally, that way the braces are not needed anymore.
Change-Id: I5afc8fa738211f884ac011079a2ee63613a46d08
Reviewed-by: Venugopal Shivashankar <Venugopal.Shivashankar@qt.io>
|
|\ \
| | |
| | |
| | | |
Change-Id: I326616356ee26d4532c6d57558c43c919f0a900d
|
| |\|
| | |
| | |
| | | |
Change-Id: I7bd70996e3372d154c6b0e47336baa22146667b0
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
These methods have real arguments.
Change-Id: Ieb4ea8396876f237adedf5df8ab5aeec1055229f
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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>
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
|\|
| |
| |
| | |
Change-Id: I70c0c672708522f7157849365cc53ee271d8e460
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
|\|
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/qml/jit/qv4targetplatform_p.h
src/quick/accessible/qaccessiblequickitem_p.h
Change-Id: Ic95075a5fad81ec997a61561bd65979dfa3b9d4d
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
|\|
| |
| |
| | |
Change-Id: I4af0bf8ec1569097d97f8ce0bb8bf1a0e4a989ec
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
|\|
| |
| |
| |
| |
| |
| | |
Conflicts:
tests/auto/quick/qquicklistview/tst_qquicklistview.cpp
Change-Id: I9588a3e2c7d590e031dd4c66905a79f0d74d3ac8
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
|\|
| |
| |
| | |
Change-Id: Ica75a71062d0613e415f2433c5c22c2e251b37cd
|
| |
| |
| |
| |
| | |
Change-Id: Id13e982ff3286ec6f369c3d5898de3da3314579d
Reviewed-by: Shawn Rutledge <shawn.rutledge@theqtcompany.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
|\|
| |
| |
| | |
Change-Id: I3567f741394f912d4312460e85555b6c39b61cb4
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
|/
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
| |
| |
| |
| |
| |
| | |
Clang doesn't like when it's inconsistent.
Change-Id: Ib306f8f647014b399b87ffff13f23eebda07757b
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
|\|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
.qmake.conf
src/qml/qml/qqmlengine.cpp
src/quick/items/qquickitemsmodule.cpp
tools/qml/main.cpp
Change-Id: Ida8daf6b4d7e675385f2f5514c446e52dedaf136
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| |
| |
| |
| |
| |
| |
| |
| | |
Contains essentially the same information, but allows the
item pointer to be null.
Change-Id: Ib848e0050c895facfbf13bddc6fec12df37a66ff
Reviewed-by: J-P Nurmi <jpnurmi@theqtcompany.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When an ObjectModel item is removed and destroyed.
Task-number: QTBUG-46798
Change-Id: Ia41dd359d9f3ec5b7af85498dc798f7ab55dca3c
Reviewed-by: J-P Nurmi <jpnurmi@theqtcompany.com>
Reviewed-by: Alan Alpert <aalpert@blackberry.com>
|