Support for QStandardItem proxies?

[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