custom model: subclass the item or the model, or store the actual data elsewhere?

[ChrisW67]

For simplicity your list of Person objects should be stored in the model object and use the standard model interface or custom extensions to modify it. The two cannot get out of sync this way and the data is stored only once. In this example your model would be a subclass of QAbstractTableModel and implement a row/column interface to display the table required by QTableView. When set as the model on a QListView you use setModelColumn() to select the name column for display.

If you already have a PopulationModel object managing a list of Person objects then you are essentially adding the QAbstractTableModel interface to it. Ensure that model actions emit the relevant signals and the views will follow changes correctly.

[Phlucious]

For simplicity your list of Person objects should be stored in the model object and use the standard model interface or custom extensions to modify it. The two cannot get out of sync this way and the data is stored only once. In this example your model would be a subclass of QAbstractTableModel and implement a row/column interface to display the table required by QTableView. When set as the model on a QListView you use setModelColumn() to select the name column for display.

If you already have a PopulationModel object managing a list of Person objects then you are essentially adding the QAbstractTableModel interface to it. Ensure that model actions emit the relevant signals and the views will follow changes correctly.

Currently my Person object inherits from QStandardItem and is stored in a QStandardItemModel. The primary interface exists without difficulty in a QTreeView at the moment, but I'm attempting to implement some tabular views (summaries, sortable filters, aggregations) of the data and struggle to do so without duplication. For example, my single QStandardItem has to get spawned into multiple items to span an entire row. Perhaps I'm doing this wrong?

Santosh's idea to add a layer of abstraction and leave the model as an interface to an underlying list seems to make sense but also sounds very complicated. I've avoided delving into the QAbstractItemModel thus far because of the number of functions and classes that are required to pull off a good implementation.

[ChrisW67]

Your "Person" object contains three pieces of information and is possibly better modelled as three separate QStandardItems in three columns.

Presenting a part of a tree as a table can be trivial or very complicated depending on exactly what is required. You can use QAbstractProxyModel instances to rearrange and summarise data to some degree.

If you can get your hands on a copy of "C++ GUI Programming with Qt4" (2nd Ed is current but maybe the 1st ed is adequate) then the chapter on Item Views and implementing a custom model are very enlightening. Tables are fairly straightforward, trees a bit more tricky.

[Phlucious]

I have a copy of that book sitting on my desk right now - a great resource! :-) Their model-view chapter is especially good and far superior to anything I saw online, but I get a little hazy on the particulars.

My tree basically contains five branches, each with its children having a unique type - say, Person, Place, and Thing to follow the earlier example. I intend to display the entire Person branch as a table, which seems like it should be straightforward. QComboBox, for example, makes displaying lists from a tree model very simple by assigning the model with QComboBox::setModel() and choosing my branch with QComboBox::setRootModelIndex(), but I don't see a similar implementation for a proxy model, even though that is what I'm shooting for.

I see that perhaps I've been thinking about the model concept backwards (tree --> table versus table --> tree). Structurally, though, the tree makes the most sense for my model

[ChrisW67]

QTableView::setRootIndex() does for the QTableView what you describe for the QComboBox. Set your tree model on the QTableView and then setRootIndex() to the QModelIndex of the parent of the Person entries.

[Phlucious]

Thanks! It hadn't occurred to me that that might be a view-based concept.

I'll see about rewiring my brain to approach this from a more model-based perspective (sub-classing QAbstractTableModel), rather than the item-based approach (sub-classing QStandardItem) I've been following up to now. Sounds like that'll flex a little more gracefully as I scale up my application.