Re: Difference between QConcatenateTablesProxyModel and KConcatenateRowsProxyModel
On Friday, April 22, 2022 3:39:08 AM CEST Fusion Future wrote: > One major difference I have found is that KConcatenateRowsProxyModel > will check if sourceModel exists when mapping from/to sourceModel, but > QConcatenateTablesProxyModel won't. So if QConcatenateTablesProxyModel > doesn't receive `rowsRemoved` signal from sourceModel, > QConcatenateTablesProxyModel will crash the program. As an outsider, I have to say that this sounds perfectly fine - even desired. Not following the QAIM protocols pedantically will have all sorts of unintended issues otherwise, some of which are hard to spot and test for. I can only recommend to test every model with the QAbstractItemModelTester, which will probably also complain about the above situation from what I understand. Cheers -- Milian Wolff | milian.wo...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: S/MIME cryptographic signature
Re: Difference between QConcatenateTablesProxyModel and KConcatenateRowsProxyModel
Hi, there's one bug that was fixed only in Qt 5.15.4 [1] which I believe was the cause for those issues. At least there was _something_ that kept me from porting notifications to it. Cheers Kai Uwe [1] https://codereview.qt-project.org/c/qt/qtbase/+/336739 Am 14.11.21 um 17:12 schrieb Fusion Future: Recently I notice that since this commit (https://invent.kde.org/plasma/plasma-workspace/-/commit/25f4cce3bf81ed8412e5053eeddd22d4366fe6ab), plasmashell will crash at start, and the backtrace indicates that QConcatenateTablesProxyModel is incompatible with LauncherTasksModel. The backtrace can be seen from https://bugs.kde.org/show_bug.cgi?id=445479 I would like to know the difference between QConcatenateTablesProxyModel and KConcatenateRowsProxyModel, because simply replacing KConcatenateRowsProxyModel with QConcatenateTablesProxyModel seems problematic. Thanks in advance.
Re: Difference between QConcatenateTablesProxyModel and KConcatenateRowsProxyModel
One major difference I have found is that KConcatenateRowsProxyModel
will check if sourceModel exists when mapping from/to sourceModel, but
QConcatenateTablesProxyModel won't. So if QConcatenateTablesProxyModel
doesn't receive `rowsRemoved` signal from sourceModel,
QConcatenateTablesProxyModel will crash the program.
For example:
# KConcatenateRowsProxyModel
```cpp
QModelIndex KConcatenateRowsProxyModel::index(int row, int column, const
QModelIndex &parent) const
{
if (row < 0) {
return {};
}
if (column < 0) {
return {};
}
int sourceRow;
QAbstractItemModel *sourceModel = d->sourceModelForRow(row,
&sourceRow);
if (!sourceModel) {
return QModelIndex();
}
return mapFromSource(sourceModel->index(sourceRow, column, parent));
}
```
# QConcatenateTablesProxyModel
```cpp
QModelIndex QConcatenateTablesProxyModel::index(int row, int column,
const QModelIndex &parent) const
{
Q_D(const QConcatenateTablesProxyModel);
Q_ASSERT(hasIndex(row, column, parent));
if (!hasIndex(row, column, parent))
return QModelIndex();
Q_ASSERT(checkIndex(parent,
QAbstractItemModel::CheckIndexOption::ParentIsInvalid)); // flat model
const auto result = d->sourceModelForRow(row);
Q_ASSERT(result.sourceModel);
return mapFromSource(result.sourceModel->index(result.sourceRow,
column));
}
```
Difference between QConcatenateTablesProxyModel and KConcatenateRowsProxyModel
Recently I notice that since this commit (https://invent.kde.org/plasma/plasma-workspace/-/commit/25f4cce3bf81ed8412e5053eeddd22d4366fe6ab), plasmashell will crash at start, and the backtrace indicates that QConcatenateTablesProxyModel is incompatible with LauncherTasksModel. The backtrace can be seen from https://bugs.kde.org/show_bug.cgi?id=445479 I would like to know the difference between QConcatenateTablesProxyModel and KConcatenateRowsProxyModel, because simply replacing KConcatenateRowsProxyModel with QConcatenateTablesProxyModel seems problematic. Thanks in advance.
