Correct structure of application model in Qt - multiple QAbstractItemModels?

[x6herbius]

For my application that deals with 3D data, I'm going to need to provide data in multiple different representations - for example, perhaps including an octree of renderable objects, or a list of all objects of a specific type. I understand that the QAbstractItemModel interface represents the application model, but should this be used as the one and only way to interact with the data itself, or is it OK to utilise it for each different representation in the more general application "model"?

In other words, should I use:

• One QAbstractItemModel overall, with each different data representation as a sub-table, and where a view chooses which model index to use as the root, or

• One QAbstractItemModel per data representation, where a view uses setModel() to choose the representation to display?

Thanks.

[Chris Kawa]

Both solutions are viable. It's just balancing between how costly is to copy(synchronize) data between the models and how complex the models would be with singular underlying data. That's something you will have to answer yourself.

Another possibility is a single base model to interact with data and another thin model layer based on QAbstractProxyModel. Two subclasses of that type can be used to represent the same data in a different way for each view and share the underlying model.

[x6herbius]

I hadn't seen QAbstractProxyModel, so I'll have a look at that and see if it looks like it'll work. I'm thinking that having singular data would be more efficient, since some data will need to reference other data anyway and managing this in several different places would be a massive pain.

[x6herbius]

@x6herbius I also have a supplementary question: let's say I want to store a list of 3D meshes in the model, and so I create a tree structure similar to a directory tree. A child item of the root model item represents a non-leaf node labelled "Meshes", and all children of this node correspond to 3D mesh items.

Would it be better to write a class for a 3D mesh item and store instances of this class in the "Meshes" sub-items, or to use the sub-items themselves to store the individual data components relevant to a mesh? In the latter case this might include another non-leaf node called "Vertices" whose child items are all QVector3D objects, or a non-leaf node called "Faces" whose children are model indices pointing to "Vertices" items.

The advantage to the latter, as far as I can see, would be that the interface remains consistent throughout the model - if you want to change a vertex position on a mesh, you can index the position using a QModelIndex like anything else, instead of needing to know about the functions that some Mesh3D object might expose to you. This would be helpful to me as my application needs to be built to cater to extension (if other objects are implemented down the line) and to make the data it holds flexible. However, it might be difficult to ensure that you are accessing what you think you are accessing - there's no guaranteed structure, so anything could potentially be added as a child of the "Vertices" node, and no type safety - and the process might be slower than just using classes as conversion to/from QVariant.