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?

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