Support for QStandardItem proxies?
-
@VRonin said in Support for QStandardItem proxies?:
I'm surprised it didn't just assert
Maybe because Qt was not compiled in debug mode. Or there is no assert and the new index check stuff is not yet used there - feel free to add it ;)
-
replace
auto x(sourceModel()->data(index));
withauto x=QIdentityProxyModel::data(index, role);
Thanks for this suggestion.
- Unfortunately, I selected a questionable member function call combination before.
- The test case is working as expected together with the statement “
return mm.text;
” now.
-
Good spot, I'm surprised it didn't just assert.
- Did I try the usage of model indexes out in appropriate way for my test case?
- Do indexes need to be different for proxy and source models?
-
@elfring said in Support for QStandardItem proxies?:
Did I try the usage of model indexes out in appropriate way for my test case?
Usually you'd want a
Q_ASSERT
that uses checkIndex()Do indexes need to be different for proxy and source models?
Yes, obviously
-
@elfring said in Support for QStandardItem proxies?:
How do you think about the introduction of a class like QProxyModelIndex then?
QAbstractPorxyModel::mapToSource
/QAbstractPorxyModel::mapFromSource
already do everything that class would do so I see no gain in introducing itShould the difference between indexes for proxy and source models be better described in the Qt documentation?
A proxy model is still a model, the docs say "Note that it's undefined behavior to pass illegal indices to item models" so I feel it is documented already
-
A proxy model is still a model,
This information is generally appropriate.
the docs say "Note that it's undefined behavior to pass illegal indices to item models"
A constraint is mentioned.
so I feel it is documented already
Now I imagine that a better class design can prevent the passing of inappropriate indexes a bit more.
How are the chances to specify that QAbstractProxyModel-like objects need to work with QProxyModelIndex objects instead? -
@elfring said in Support for QStandardItem proxies?:
Now I imagine that a better class design can prevent the passing of inappropriate indexes a bit more.
Agree that's why I said:
I'm surprised it didn't just assert.
How are the chances to specify that QAbstractProxyModel-like objects need to work with QProxyModelIndex objects instead?
QAbstractProxyModel
is a subclass ofQAbstractItemModel
and the view should not care whether the model it's attached to is a proxy or not
-
@elfring said in Support for QStandardItem proxies?:
Can overloaded functions (from a specific proxy class) help any more to detect questionable indexes?
It can help but there's no bullet proof solution.
In the meantime I submitted a change to QStandardItemModel that would have made your bug assert in debug
-
In the meantime I submitted a change to QStandardItemModel that would have made your bug assert in debug
I find it interesting that my clarification request triggered such a software evolution finally.
Would you like to continue the development discussion also around proxies for QStandardItem (or eventually other classes)? -
@VRonin said in Support for QStandardItem proxies?:
assert in debug
But only when Qt was compiled in debug mode which is for sure not the case...
-
@Christian-Ehrlicher said in Support for QStandardItem proxies?:
But only when Qt was compiled in debug mode
Yes, as the docs say using invalid indexes remains undefined behaviour, I am just trying to help users spot these cases
24/27