Views should instantiate their proxy models.

Keep a single source model though because that is your data and it belongs in c++.

Use multiple proxy models.

OK, will do. I wasn't sure whether this was a viable alternative, or if I should somehow use proxy models as sparingly as possible.

Expose your proxy model as a type with some properties...

I'm not sure I understand what this means.

Thanks...

Views should instantiate their proxy models.

Keep a single source model though because that is your data and it belongs in c++.

If you correctly implemented your proxy you should use it as such: model: equipmentValveProxy

I do use it exactly that way elsewhere.

My situation is that I need to display various subsets of the equipment model in different parts of the UI. Even the valve subset will require different selection criteria on different views. What I really need, probably, is some way to make filterAcceptRows() smarter, so it would behave differently based on the use case. Absent that, this function that returns a list (and I'd have more functions like it) was the best I could think of.

I know - I left that out for brevity.

but you use model: equipmentValveProxy.getReturn() with a function signature of QList<Equipment *> EquipmentValveProxy::getReturn()

You are not using it as a QSortFilterProxyModel and it inheriting QSortFilterProxyModel has no effect in the code you provided.

If you correctly implemented your proxy you should use it as such: model: equipmentValveProxy

@mzimmers why would name be recognized?

You are using a QList as a model. QList is not a QAbstractItemModel and thus don't have model role. This means that the ListView is only exposing the elements of the list to the delegates via modelData. text: modelData.name would work in your case.

Aha.

Your solution works, but your answer made me realize I have another issue with this approach: by use of a simple list, my UI won't be updated automatically when the model changes. I can see I still have some work to do.

Also when talking about proxy model in Qt we usually mean QAbstractProxyModel like QSortFilterProxyModel. They operate over a QAbstractListModel. You don't have any of those in your above code.

I know - I left that out for brevity.

class EquipmentValveProxy : public QSortFilterProxyModel
{
    Q_OBJECT
    ...

You are using a QList as a model. QList is not a QAbstractItemModel and thus don't have model role. This means that the ListView is only exposing the elements of the list to the delegates via modelData. text: modelData.name would work in your case.

Also when talking about proxy model in Qt we usually mean QAbstractProxyModel like QSortFilterProxyModel. They operate over a QAbstractListModel. You don't have any of those in your above code.