Implementation strategy QTableView model/proxy/delegate with group titles

Hello!

I need some ideas about the best way to implement group titles in a QTableView.
I already have a special model (which combines multiple lists into a single list), an ItemDelegate (which draws the image and decoration in the TableView) and a ProxyModel, which I need for sorting and filtering.

Now I want to add group titles (depending on the sorting type I selected) to the list.

The result should look like this:

Attachment 11024

My questions are now:

- What is the best strategy to implement this?
- Can I implement the groups in the ProxyModel? Or do I have to do it in the (Source)Model?
- Is it possible to control all parameters (like appearance, column-span and size) from the ProxyModel?
- Can I pass information from the ProxyModel to the ItemDelegate?

I think somebody has already implemented something similar already and can share his experience?!
Maybe there I already some example code for this available?!


Any answers and hints are welcome...

Thx
Sven

You should implement the group titles, etc. in the proxy. The tricky part will be correctly implementing the mapToSource() and mapFromSource() methods of the proxy. The proxy's rowCount() method will have to take into account the extra rows fro the group titles, and the data() method will have maintain a local record of where the group titles occur so it can either supply a title or switch back to the source model to retrieve a detail line.

As for sources, believe me, I've looked. There are lots of commercial solutions; the closest open source project I have found is QtRpt but it carries too much baggage along with it for me and I don't know if it can be used for display other than printing.

Hello!

Today I read in another post (about prepending rows to a model in a proxy model), that it is not possible to add additional rows to a model using a proxy model. Rows can only be sorted and filtered out.
The reason should be, that when the base model updates its persistent indexes, the proxy cannot know in all cases how to update the persistent index of the extra rows.

Because adding group titles would be something similar: Is this correct?

If this is correct, what other strategy should I use to implement this?

Now I'm uncertain again....

That's not true at all. I have a QAbstractItemModel that represents a tree-structured underlying C++ data hierarchy. When I display that in a tree view, I use the bare model, which reports to the tree view that it has either 3 or 4 columns, depending on the level in the tree (branches have 3 columns, leaves have 4). I use a proxy model to flatten this tree into a table, and at the same time add 15 columns to each row. The extra columns represent details of the underlying data that aren't shown in the tree view. This works fine. The QAbstractItemModel that is the source model for the proxy doesn't know anything about these extra columns, so it has no persistent indexes that can be messed up.

I even add more proxies where this table-shaped proxy serves as the source model to pull out individual columns for plotting in charts and graphs. This works fine, too. On top of that, there are selection models for every view that when, for example, something is selected from a chart, the corresponding items are selected from the table and the tree.

The table-shaped proxy model does keep persistent indexes for the source model to aid in mapping, but these are updated every time the source model is updated so there is never a possibility of the source and proxy getting out of sync. Likewise, the proxies that pull data out of the table proxy automatically update too. You just have to make sure that if you implement a custom proxy, it responds to all the signals issued by the source model when something changes.

As for a strategy for implementing this, I was thinking that using a proxy that represents your table as a tree might be suitable. The group-level headers would serve as the parents for each of the items that appear in the group below it. The proxy would essentially examine the source model to identify the rows that belong in each group, and create QModelIndex parents for them.

I do not know what an out-of-the-box QTableView would do with this - it might display only the parent (group) indexes, or if you are lucky, it will flatten the whole thing out. My hunch is it will only display the top-level parents, so you may have to implement a custom table view to expand the whole thing.