| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds a specific abstract QQmlComponent subclass,
QQmlAbstractDelegateComponent, and a default implementation,
DelegateChooser, that, together with the type DelegateChoice
allows determining the delegate type by role and/or index.
The patch also adds QQmlAbstractDelegateComponent support
to QQmlTableInstanceModel, that is a simplified version of
the delegate model, currently only used in the new table view.
DelegateChoosers are intended to behave just like Components
in the context of the view. This means that they can be declared
outside of the view, and also in separate files, and the same
delegate component can be used at the same time in multiple views.
[ChangeLog][QtQuick][Item Views] Added a DelegateChooser Component
to host DelegateChoice instances to choose different delegates in
an Item View (e.g. TableView) depending on model roles.
Done-with: Michael Brasser <michael.brasser@live.com>
Task-number: QTBUG-26681
Change-Id: Ibe24a31daf9142c8a9ff45ef6c65da0aec8a14dc
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
It turns out that using a maxTime of 2 when draining
the pool was a bit naive. If e.g the width of the
table is greater than the height, it starts releasing
pooled items to quickly. So change the logic to be more
dynamic, and to calculate what the maxTime should be
based on the geometry of the table.
Change-Id: Ifeed62789575f98cff063f550f45eb54ef312fdb
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Equal to QQmlDelegateModel, we need to listen for changes done to
existing model items, and notify existing delegate items about it.
Otherwise, they will not stay in sync with the model.
By accident, this sort of worked in QQuickTableView already, since
it would rebuild the whole table for every model update. This
is really slow, and completely unnecessary.
Change-Id: I10750ff387f8b455d0f27c50a17926d9beb6dd03
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch will make it possible for TableView to reuse delegate items.
The API lets TableView (or any kind of view in theory) specify if an
item is reusable at the time the item is released.
Reusing delegate items is specified per item, meaning that the view
can choose to release some items as reusable, but others not. If the
view never releases any items as reusable, no items will be
added to the pool, and hence, no items will be reused.
If the view releases an item as reusable, the model will move it
to the reuse pool rather than destroying it (if the items ref-count
is zero, and not persisted). The next time the view asks the model for
a new item, the model will first check if the pool already contains an
item, and if so, use it. Otherwise it will create a new item, like before.
Items in the pool are supposed to rest there for a short while. Ideally
only from the time items are flicked out on one side of the view, until
we reuse them when new items are flicked in on the oppsite side. One big
reason for this is that we have no way of hibernating items in QML, so
they will effectively stay alive while inside the pool. This is not
ideal, but still a huge performance improvement over what we had before,
where all items are always created from scratch. If hibernating objects
will ever be possible, it should be easy to extends the current logic to
take advantage of this.
Already existing tests for QQuickTableView should verify that no
regressions are introduced with this patch. Since recycling of items
is driven from the view, auto tests for this functionality is included
with the patch for implementing reuse support in TableView (coming
in a subsequent patch).
Change-Id: I28aa687251ce3e7e1de0b1c799fdbf44d8867d45
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
|
|
This patch will add a new model class: QQmlTableInstanceModel.
It will be used by QQuickTableView to communicate with the data
model, instead of using QQmlDelegateModel.
The reason we abandon QQmlDelegateModel for QQuickTableView, is because
QQmlDelegateModel was written from the start to only support list models,
not table models. And to work around this, we proxy table models as a list
models, and combine all columns to form one big list.
This as some disadvantages. First and foremost because QQmlDelegateModel
is using QQmlListCompositor internally. QQmlListCompositor can combine
many different list models into one big list model, and divide them into
groups. Any change done to a list model will also be mirrored in the list
compositor. The compositor will further create QQmlChangeSets describing
such model changes, which will then be emitted by QQmlDelegateModel so that
the view can transition in the same changes.
This flow is especially bad when adding/removing a new row in a table.
In that case, since the table looks like as a list, the list compositor will
need to update its own internal structures for each item in the new row. So
if you have 1000 columns, 1000 updates will be processed.
Even worse, since the list compositor create QQmlChangeSets for each item in
the row, the view will end up receiving 1000 signals about the change.
Combine this with the fact that QQmlDelegateModel contains a lot of
undocumented complex code for dealing with groups, which is not needed or
used by TableView (or ListView for that sake *), adding a new
QQmlTableInstanceModel that understands table models, is the right solution.
Auto testing the new class will be done from QQuickTableView, once it takes
it into use.
* Note: The fact that TableView/ListView is using QQmlDelegateModel internally
to communicate with the data model is a private implementation detail. The
application will never have access to this model (and can therefore not
create any groups on it etc). The application can, however, create its own
DelegateModel and assigns it to TableView/ListView. But this is a different
issue, and will continue to work as before.
Change-Id: If1c35c27e75f236161df84ecb1d919aa3050f5a0
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
|
