diff options
author | Richard Moe Gustavsen <richard.gustavsen@qt.io> | 2018-06-23 11:33:04 +0200 |
---|---|---|
committer | Simon Hausmann <simon.hausmann@qt.io> | 2018-07-16 13:54:36 +0000 |
commit | e732e5c969b8ee3ddfb7ae33761ddc105e0af4cb (patch) | |
tree | 62409887844c2c9d5967268bedd33dd9687cd421 /src/qml/types/qqmldelegatemodel_p_p.h | |
parent | b98a8277d82f0a749aadaeff0c5f042cd359868f (diff) |
QQmlTableInstanceModel: add new TableView helper class
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>
Diffstat (limited to 'src/qml/types/qqmldelegatemodel_p_p.h')
-rw-r--r-- | src/qml/types/qqmldelegatemodel_p_p.h | 6 |
1 files changed, 3 insertions, 3 deletions
diff --git a/src/qml/types/qqmldelegatemodel_p_p.h b/src/qml/types/qqmldelegatemodel_p_p.h index 4c7069966b..c4e253800a 100644 --- a/src/qml/types/qqmldelegatemodel_p_p.h +++ b/src/qml/types/qqmldelegatemodel_p_p.h @@ -68,7 +68,7 @@ typedef QQmlListCompositor Compositor; class QQmlDelegateModelAttachedMetaObject; -class QQmlDelegateModelItemMetaType : public QQmlRefCount +class Q_QML_PRIVATE_EXPORT QQmlDelegateModelItemMetaType : public QQmlRefCount { public: QQmlDelegateModelItemMetaType(QV4::ExecutionEngine *engine, QQmlDelegateModel *model, const QStringList &groupNames); @@ -196,8 +196,8 @@ public: void statusChanged(Status) override; void setInitialState(QObject *) override; - QQmlDelegateModelItem *incubating; - QQmlDelegateModelPrivate *vdm; + QQmlDelegateModelItem *incubating = nullptr; + QQmlDelegateModelPrivate *vdm = nullptr; int index[QQmlListCompositor::MaximumGroupCount]; }; |