| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
The resetModel() signal indicates that the model is reset. Previously
there was no note that the signal is emitted also when endResetModel()
is called.
Task-number: QTBUG-23755
Change-Id: I6c3c1ccef580e9c1112c3af79912cffca675e140
Reviewed-by: Robin Burchell <robin+qt@viroteck.net>
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is broken in most uses because it emits modelAboutToBeReset()
after actually resetting the internal data instead of before.
That is, usually it is used like this:
myData.clear();
reset();
Which should be
beginResetModel();
myData.clear();
endResetModel();
Change-Id: I7b00a1e40c4915930944340764074efc29faaf5a
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The existence of QAbstractItemModel virtual methods
moveRow, moveColumn, moveRows, and moveColumns
is implied by the existence of
beginMoveRows, endMoveRows, beginMoveColumns and endMoveColumns.
However, these were not actually provided by QAbstractItemModel.
With this change, subclasses can implement support for moving rows
and columns following the same pattern as for insert* and remove*.
Change-Id: Iad8b2223d4b9303abb6459c174a82ffed71a0fdf
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
|
| |
|
|
|
|
|
| |
Replace Nokia contact email address with Qt Project website.
Change-Id: I431bbbf76d7c27d8b502f87947675c116994c415
Reviewed-by: Rohan McGovern <rohan.mcgovern@nokia.com>
|
| |
|
|
|
| |
Change-Id: I05970302d4f52d092a7c65a45b9e5a3570b1d144
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
|
| |
|
|
|
|
|
| |
Change-Id: I4001fcabc67e5b46465b3c9111c33247c52e5788
Reviewed-by: David Faure <faure@kde.org>
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
Reviewed-by: David Faure <david.faure@kdab.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is consistent with the rest of the API of QAbstractItemModel
(which is virtual) and removes the need for code like this
in the constructor (where it doesn't belong):
QHash<int, QByteArray> myRoleNames = roleNames();
myRoleNames.insert(Qt::UserRole + 1, "myCustomRole");
setRoleNames(myRoleNames);
in favor of
MyModel::roleNames() const {
QHash<int, QByteArray> myRoleNames = QAbstractItemModel::roleNames();
myRoleNames.insert(Qt::UserRole + 1, "myCustomRole");
return myRoleNames;
}
which is consistent with all other QAIM API (eg, flags()).
This is a source compatible change.
Change-Id: I7e1ce17f8dab2292c4c7b6dbd3c09ec71b5c793b
Reviewed-by: David Faure <faure@kde.org>
Reviewed-by: Marius Bugge Monsen <marius@cutehacks.com>
|
| |
|
|
|
| |
Change-Id: I02f2c620296fcd91d4967d58767ea33fc4e1e7dc
Reviewed-by: Rohan McGovern <rohan.mcgovern@nokia.com>
|
| |
|
|
|
|
|
|
| |
It is not the responsibility of the view to insert data into the
model after a dropMimeData call.
Change-Id: Ib2dedddb3239af0e2bf722a28081c68677e6b2af
Reviewed-by: David Faure <faure@kde.org>
|
|
|
Change-Id: Ib505520dd5b52743634befbf3f148d7f8c21ec44
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
