Support for QStandardItem proxies?

elfring

does if (x.canConvert<my_message>()) return false?

I get this impression after I see three asterisks in the display from my test widget on the screen.

what is your intention in this code snippet?

I am trying also to get more familiar with the provided programming interfaces around models and views.

You are leaking all 3 of the models.

I do not really need my own clean-up for this software experiment at the moment.

The view does not own the model

Thanks for your reminder.

Do you spot any other suspicious implementation details?

elfring

does `if (x.canConvert<my_message>()) return false?

I have added a test output for my local variable “x”. The programming interface “qDebug()” provides the information “QVariant(Invalid)” then so far.

Would you like to help with finding an explanation for this software behaviour?
How can a source model work here?

Christian Ehrlicher

@elfring said in Support for QStandardItem proxies?:

auto x(sourceModel()->data(index));

How should this work at all? http://doc.qt.io/qt-5/qidentityproxymodel.html#mapToSource

VRonin

Good spot, I'm surprised it didn't just assert. I got shouted at in code review for having models that didn't assert when index.model()!=this

@elfring replace auto x(sourceModel()->data(index)); with auto x=QIdentityProxyModel::data(index, role);

Christian Ehrlicher

@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 ;)

elfring

replace auto x(sourceModel()->data(index)); with auto 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.

elfring

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?

VRonin

@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

Yes, obviously

Should the difference between indexes for proxy and source models be better described in the Qt documentation?
How do you think about the introduction of a class like QProxyModelIndex then?

VRonin

@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 it

Should 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

elfring

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?

VRonin

@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 of QAbstractItemModel and the view should not care whether the model it's attached to is a proxy or not

elfring

the view should not care whether the model it's attached to is a proxy or not

Can overloaded functions (from a specific proxy class) help any more to detect questionable indexes?

VRonin

@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

elfring

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)?

Christian Ehrlicher

@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...

VRonin

@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