| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Amends 3b806a18cc665b5ae0e12d45fe170bfc3f00352a.
Eric's change tried to tackle the issue by making the PartModel more
well-behaved. However, this still left some issues, as exhibited by the
linked bug. This time, we simply make the repeater more robust, and
setup d->deletables if it's not done yet.
Pick-to: 5.15
Fixes: QTBUG-71964
Change-Id: I58c80c84f73fddaea5d6030f92ffff219ecf2b71
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
| |
|
|
|
|
|
|
|
|
| |
Otherwise we would set the same object as extraObject and as
contextObject. That spells trouble when tearing down the context.
Fixes: QTBUG-79958
Change-Id: I97fd0bf111304d06cff35eda46d4b4c6eefdaccc
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a delegates declares a required property of a given name, and that
name exists as a role in the model, we set the property accordingly.
The same holds true for the special properties that come from the
QQmlDelegateModel like "index" and "model".
All roles are still injected into scope and thus accessible;
changing this in Qt5 would be tedious or even impossible while still
maintaining backwardscompatibility with delegates that do not use
required properties.
Change-Id: I4f388ba549c42f1ff9822bdb3b8357c4d45e4b66
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
VisualDataModel, VisualDataGroup, and VisualItemModel
are replaced with DelegateModel, DelegateModelGroup, and ObjectModel
respectively (since 7cad0e52c5a020bd29635e9912fd8946a6b48124).
git grep -l 'VisualDataModel' | xargs sed -i 's/VisualDataModel/DelegateModel/g'
git grep -l 'VisualDataGroup' | xargs sed -i 's/VisualDataGroup/DelegateModelGroup/g'
git grep -l 'VisualItemModel' | xargs sed -i 's/VisualItemModel/ObjectModel/g'
Change-Id: Ie91b37b204f08a5d1f1f38594fb22ed70a6e2080
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When assigning a JS owned model or delegate to an item view, we must
ensure that they stay alive as long as the item view. This happens
easily for example when doing something like
delegate: Qt.createComponent(...)
This patch takes the minimally invasive approach by changing the QObject
parent of such objects.
Task-number: QTBUG-50319
Task-number: QTBUG-51620
Change-Id: Ie6384b8dd93dcdc62d49f64b38173b3fc4ffd3b3
Reviewed-by: J-P Nurmi <jpnurmi@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When receiving the modelUpdated signal from the delegate model, the
repeater - unlike other views - queries for the objects right away. That
may result in instant incubation and when using Packages, we will end up
delivering the initItem signal emission for the parts models via
QQmlDelegateModelGroupPrivate::initPackage for _both_ repeaters
immediately. For the first repeater that's expected, but for the second
repeater that means initItem is received before modelUpdated was called.
That is very confusing for the repeater as d->deletables is not set up
yet.
While it's possible to make the repeater more "robust" towards such
behaving models, it seems cleaner to make the model behave well, by
ensuring that we emit initItem after modelUpdated.
Task-number: QTBUG-50349
Change-Id: Id2f3ba135e34d0111c8896bb4ecdfe51c8c649da
Reviewed-by: Michael Brasser <michael.brasser@live.com>
Reviewed-by: Erik Verbruggen <erik.verbruggen@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In complicated cases where the model moves rows around while
the view is running slow (perhaps during high CPU load),
there were cases when Repeater would call
movedItem->stackBefore(deleteableItem), but deleteable items
can be null, so there was often an error
QQuickItem::stackBefore: Cannot stack before 0x0, which must be a sibling
and occasionally a crash. Now we check both the callee and the
parameter to stackBefore to make sure neither of them are null.
Task-number: QTBUG-54859
Change-Id: I45a8b2939c16b9bbe3a802ddd348dc55f51061a7
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| |
|
|
|
|
|
|
|
| |
Use the same ordering as item views and release before unparenting.
Change-Id: I0346342cfcaf9385d8385769795dd5ba35fc43aa
Task-number: QTBUG-46828
Reviewed-by: Liang Qi <liang.qi@theqtcompany.com>
Reviewed-by: Robin Burchell <robin.burchell@viroteck.net>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Following the ListModel API:
- object get(index)
- append(object)
- insert(int index, object)
- move(int from, int to, int n)
- remove(int index, int n)
[ChangeLog][QtQml][ObjectModel] Added get(), append(), insert(), move()
and remove() methods.
Change-Id: I592e55b7c4c933a1100191bf5a9405944b347172
Reviewed-by: Alan Alpert <aalpert@blackberry.com>
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@theqtcompany.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
When listening for Component.onCompleted on the items emitted by the
Repeater, the items' stacking order was not properly set up.
The stacking order was corrected after Component.onCompleted was emitted,
which was undesirable in some cases.
Task-number: QTBUG-45423
Change-Id: Ib96b3de81db556b09fb5fc8bd27ce19223014f7e
Reviewed-by: Alan Alpert <aalpert@blackberry.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
since this breaks for asynchronous models, because item creation order
is not guaranteed. We always have the index
for what item to create, so we do not need it either.
Change-Id: Ib8ce25ac342f5cce4784c56e6a91cf70136566b3
Task-number: QTBUG-38879
Task-number: QTBUG-39001
Task-number: QTBUG-44250
Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
This way, the indices for itemRemoved will make sense consistently.
This was broken with 5f5aba5b6e690ca54e66f41b93474f7e67e83c8b, dated November
2011.
Task-number: QTBUG-42243
Change-Id: I5fecfd4174049f51e0cec90e40e6332de5d5bf01
Reviewed-by: Gunnar Sletta <gunnar@sletta.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
It has been reported multiple times (with different back traces) that
the QQmlDelegateModel tries to access a dangling QQmlContext pointer.
The scenarios for reaching this point differ slightly, one such scenario
is very late model activity during the scene destruction. The provided
test-case simulates that and the provided patch guards the QQmlContext
in a QPointer.
Task-number: QTBUG-39780
Change-Id: I594ee4918cd1b78c5db5c164314e85e9eea99fbd
Reviewed-by: Alan Alpert (Personal) <416365416c@gmail.com>
|
| |
|
|
|
|
|
| |
remove trailing spaces and expand tabs
Change-Id: Ieacb9d096b612c45d1a64700044c114d1f7522bc
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
|
| |
|
|
|
|
|
| |
Task-number: QTBUG-200461
Change-Id: Ia8e48668960ac005cf773bf6f53da40f1c753b9b
Reviewed-by: Alan Alpert <aalpert@blackberry.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The repeater item previously stored a raw QObject pointer in
a variant. When this pointer was a dynamic list model element
that was deleted, the variant would continue to hold a stale
pointer. Change repeater to use a guard object to hold the model
when it is a QObject. Continue to use a variant to hold models
that are not based on QObject to maintain same semantics.
Change-Id: Ie100947132923803263c725e86efa68206382f12
Reviewed-by: Martin Jones <martin.jones@nokia.com>
|
|
|
Symbols beginning with QDeclarative are already exported
by the quick1 module.
Users can apply the bin/rename-qtdeclarative-symbols.sh
script to modify client code using the previous names of the
renamed symbols.
Task-number: QTBUG-23737
Change-Id: Ifaa482663767634931e8711a8e9bf6e404859e66
Reviewed-by: Martin Jones <martin.jones@nokia.com>
|
