aboutsummaryrefslogtreecommitdiffstats
path: root/src/qml/types/types.pri
diff options
context:
space:
mode:
authorRichard Moe Gustavsen <richard.gustavsen@qt.io>2018-06-23 11:33:04 +0200
committerSimon Hausmann <simon.hausmann@qt.io>2018-07-16 13:54:36 +0000
commite732e5c969b8ee3ddfb7ae33761ddc105e0af4cb (patch)
tree62409887844c2c9d5967268bedd33dd9687cd421 /src/qml/types/types.pri
parentb98a8277d82f0a749aadaeff0c5f042cd359868f (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/types.pri')
-rw-r--r--src/qml/types/types.pri6
1 files changed, 4 insertions, 2 deletions
diff --git a/src/qml/types/types.pri b/src/qml/types/types.pri
index 5d75759281..6a74d70a0e 100644
--- a/src/qml/types/types.pri
+++ b/src/qml/types/types.pri
@@ -6,7 +6,8 @@ SOURCES += \
$$PWD/qqmlobjectmodel.cpp \
$$PWD/qquickpackage.cpp \
$$PWD/qquickworkerscript.cpp \
- $$PWD/qqmlinstantiator.cpp
+ $$PWD/qqmlinstantiator.cpp \
+ $$PWD/qqmltableinstancemodel.cpp
HEADERS += \
$$PWD/qqmlbind_p.h \
@@ -17,7 +18,8 @@ HEADERS += \
$$PWD/qquickpackage_p.h \
$$PWD/qquickworkerscript_p.h \
$$PWD/qqmlinstantiator_p.h \
- $$PWD/qqmlinstantiator_p_p.h
+ $$PWD/qqmlinstantiator_p_p.h \
+ $$PWD/qqmltableinstancemodel_p.h
qtConfig(qml-list-model) {
SOURCES += \