QTableView add a remove button to each row

[StrikeByte]

What's the best way to add a remove button to each row in a QTableView (without modifying the model)
Is there anyway to do this in a delegate (the model doesn't have a row for the button)

[wysota]

In the delegate you should draw something that looks like a button using QStyle and handle events for clicking such artificial button.

[StrikeByte]

Thx for the answer, this was not what I was hoping for :p

I was thinking of using a proxymodel to add the extra column and add a styleddelegate to it, dunno if this is possible

just was checing into QProxyModel but it says its obsolete, it looks like i will need to write my own. oh just found that there is a QAbstractProxymodel I can use


I've just tried it and it seems to work with a QAbstractProxymodel and a delegate.
The proxymodel just adds an empty column and the delegate creates an pesistent editor in it (a modified QPushbutton)
It's not clean but it works

[pitonyak]

I was thinking of using a proxymodel to add the extra column and add a styleddelegate to it, dunno if this is possible

just was checing into QProxyModel but it says its obsolete, it looks like i will need to write my own. oh just found that there is a QAbstractProxymodel I can use


Smart thinking.....

Can you use the QSortFilterProxyModel? It is not marked as deprecated / obsolete.

http://qt-project.org/doc/qt-5/qsortfilterproxymodel.html

[d_stranz]

I've just tried it and it seems to work with a QAbstractProxymodel and a delegate.
The proxymodel just adds an empty column and the delegate creates an pesistent editor in it (a modified QPushbutton)

I started to suggest this yesterday, but didn't have the time to complete my reply. Glad you tried it and got it to work.


Can you use the QSortFilterProxyModel? It is not marked as deprecated / obsolete.

QSortFilterProxyModel is not appropriate for this use. It is used in cases where you want to 1) remove certain rows or columns from the source model and / or 2) display the source model sorted in a different order without changing the source model. There are several additional methods that must be implemented in QSortFilterProxyModel which have no relevance to the OP's problem. In his case, he wants to pass the source model unchanged, and simply add a new virtual column with a pushbutton in it. Depending on where he adds the virtual column, he won't have to do anything in QAbstractProxyModel's virtual methods except return QModelIndex instances that map directly to or from the same row and column of the source.

[wysota]

I've just tried it and it seems to work with a QAbstractProxymodel and a delegate.
The proxymodel just adds an empty column and the delegate creates an pesistent editor in it (a modified QPushbutton)
It's not clean but it works

Did you try it with a large model, say... 1000 rows? What was the performance?

[StrikeByte]

No sorry my model only contains like 50 rows


just did a quick test with 5000 items, took 8 seconds (my model does some name checking an makes a unique name for each item, need to check it for a faster algorithm)
adding items to the model doesnt make a difference when using the proxymodel or not
scrolling through the list works just fine

I still do not know what happens on a slow pc

thx for the question, now I see I need to optimize my model a bit :p

[d_stranz]

need to check if for a faster algorithm

You might be able to use qHash() or one of the Qt classes that incorporate it (QMap, QSet, or QHash). You probably don't need to store the keys, just the hash values.

[StrikeByte]

Thx for the tip, but all the items are stored in a QMap already, with theire internal unique key.

The algorithm is making a unique name for the users input:
for example if a user adds an item called "test" if he/she tries to add another item called "test" it will rename it to "test_1", another "test_2",,, etc

[d_stranz]

If you are doing this in response to user input, then it is unlikely that performance will ever be an issue. Even if you have a large number of names stored, the time it takes to look one up in a QMap (whether it finds it or not) is negligible compared to human response time.