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

[dhalbert]

I am trying to figure out the "best" way stylistically in Qt to implement a simple custom model. As a strawman example, suppose I want to display a read-only list of text items, some of which may be marked with an asterisk. I want to be able to change what's in the list and turn the asterisks on and off:

ABC
DEF*
GHI

I want my model or model item to store two properties, a string "text" and a bool "starred". The view displays the text and adds an asterisk if "starred" is true.

I can think of several ways to do this. I'd use a QListView for display.

1. Subclass QStringListModel and have it store the "starred" property in a user-defined role. Store the base text in the DisplayRole. Reimplement data() to check the user-defined role and add "*" to the text as necessary when the DisplayRole is requested.

2. Subclass QAbstractItemModel to store the properties in some private data structure and compute the displayRole value from those properties. Don't actually store anything in roles.

3. Use QStandardItemModel as is, without subclassing. Instead, subclass QStandardItem to store my properties and compute the displayRole value from those properties.

4. Have my own class that with appropriate set/get functions that store the state. When the state changes, my class will update the QStringListModel's text appropriately. So the QStringListModel ends up being a sort of "view" on the actual data.

In general I find the model classes presented by Qt to be fairly constrained. They don't map very well to my own idea of a model being some arbitrary data object. For a multivalued object, Qt lets you store the values as columns, or as roles, but both correspond closely to what a view wants, not how the actual data might be structured.

Any comments? Maybe all of these ways are just fine. Most of the questions I've found on subclassing models have to do with complicated tree or table models, but not basic questions about mapping existing data into models.

Thanks,
Dan

[barnabyr]

There's one option missing in your list which is a nice way ...

Add the starred property to some user defined role in the model (as you stated) then
use a delegate in the view to draw the data differently if the starred property is found.

In this trivial example I doubt there's any performance reason to do it one way or another. The way above just helps you separate data from drawing.

[Phlucious]

I realize I'm resurrecting an old post, but I find myself with the exact same question and don't feel that it has been answered thoroughly. If one chooses to store data in a QObject with multiple values, what is the most logical Qt way to implement the model-view-delegate framework to view and edit the data?

The OP's example is very limited, so I thought I'd flesh it out a little more. Suppose I have a set of Person objects that I now want to display in a QListView and in a QTableView. Each Person has a Name, Height, and Weight. The QListView would display the list of Person objects by their name, while the QTableView would display each Person object as a row, with a column each for Name, Height, and Weight.

Obviously it's very straightforward to create a QStandardItemModel for each scenario, with a QStandardItem for each cell, but it doesn't make sense to me that the underlying model associates each item with every property when I think about it in terms of each object. It seems very cumbersome to manually connect each item to the original to ensure that the data remains linked, and the option to create duplicate items seems even less favorable. How do people normally implement this in Qt?

[Santosh Reddy]

How do people normally implement this in Qt?

Implement a Custom / derived QAbstractTableModel, where the model can store a person information any way it wants to, may be like "Person objects" as you say.

This model can used to view both on a QListView and QTableView

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