extending functionality of a proxy model

mzimmers

Hi all -

I've implemented a proxy model that filters based on a property of the item. I want to use this proxy model in different places, but with additional filtering. Here's a code snippet:

class Equipment : public QObject
{
    Q_OBJECT
    QML_ELEMENT

    Q_PROPERTY(QString name READ name WRITE setName NOTIFY nameChanged FINAL)
    ...
}
    
QList<Equipment *> EquipmentValveProxy::getReturn()
{
    QList<Equipment *> list;
    ... // conditionally add stuff to list.
    return list;
}

I try to use this function in QML as follows:

ListView {
    model: equipmentValveProxy.getReturn()
    delegate: valveName
    Component {
        id: valveName
        Label { text: name } // runtime error: not defined.
    }

but "name" isn't recognized here. Is what I'm trying to do even possible? Or do I need a new proxy model for this purpose?

Thanks...

GrecKo

@mzimmers Use multiple proxy models. Expose your proxy model as a type with some properties to tweak the criterias as you need instead of having a single one..

Views should instantiate their proxy models.

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

GrecKo

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

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.

mzimmers

@GrecKo said in extending functionality of a proxy model:

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

GrecKo

@mzimmers said in extending functionality of a proxy model:

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

@GrecKo said in extending functionality of a proxy model:

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.

GrecKo

@mzimmers Use multiple proxy models. Expose your proxy model as a type with some properties to tweak the criterias as you need instead of having a single one..

Views should instantiate their proxy models.

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

mzimmers

@GrecKo said in extending functionality of a proxy model:

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