A bit faster, not that this is the most important case for it. Change-Id: I3e50bd4a45d2b60c105a9315ccf0b2c34502cb8d Reviewed-by: Michael Brasser <michael.brasser@live.com>
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>
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>
Historically, Repeaters were avoided by their parent positioners by only accepting items with a width *and* height greater than zero. (Repeater is an item where both width and height defaults to zero). Later, QQuickItemPrivate::isTransparentForPositioner() were added to fix similar problems with item.layer and item.layer.effect (change da15ea0f3b5805db657f13060c21efa78f10cde2) Since isTransparentForPositioner is now available, we can therefore mark mark QQuickRepeater also as transparent for positioners. This also enables Qt Quick Layouts to have a much better heuristic on which items should be ignored or not. AFAICS, this will only break if people actually resized their repeaters (and they thus got included in their parent positioners). I cannot see why anybody would have wanted this behavior (and depend on it). Therefore, there is a risk of regression, but I doubt that this is behavior that people would expect not to break. [ChangeLog][QtQuick][Repeater] Positioners will now always ignore Repeaters. Previously, Repeaters were ignored by Positioners when their width or height were 0. Change-Id: I1132b753869fdc398eaeabeb9cce7cbf545dbbed Task-number: Preparation for QTBUG-44077 Reviewed-by: Alan Alpert <aalpert@blackberry.com> Reviewed-by: Jan Arve Sæther <jan-arve.saether@theqtcompany.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>
Qt copyrights are now in The Qt Company, so we could update the source code headers accordingly. In the same go we should also fix the links to point to qt.io. Change-Id: I61120571787870c0ed17066afb31779b1e6e30e9 Reviewed-by: Iikka Eklund <iikka.eklund@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>
QVariant comparison in setModel() started failing because JS arrays are now passed as a QJSValue. Re-assigning the same array content should not trigger a model change. This change restores the old behavior it had before, when JS arrays were passed as QVariantLists. Change-Id: I1882b3531f2893b116dbd817edeecab1ae812ce8 Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
- Renamed LICENSE.LGPL to LICENSE.LGPLv21 - Added LICENSE.LGPLv3 & LICENSE.GPLv2 - Removed LICENSE.GPL Change-Id: I84a565e2e0caa3b76bf291a7d188a57a4b00e1b0 Reviewed-by: Jani Heikkinen <jani.heikkinen@digia.com>
The class had a vtable, clashing with assumptions about Managed objects. The derived classes where actually only cosmetic sugar on top of the basic change class. Clean this up and unify the functionality in the base class. In addition adjust the class to the new data layout. Change-Id: I8677f6c71465381f7ebdf82eb6025fda6d137ec3 Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>