A question about Model/View programming

[awhite1159]

I started to familiarize myself with Qt about two weeks ago. I have designed a Network Backup Simulator's base data structure and its ability to pass messages in an undirected acyclic graph from vertice to vertice. All input and output is currently via cin and cout so it runs as a console program.

The data structure relies heavily on polymorphism and has private members defined at different levels in the subclassing.

It appears that Model/View implementation seems to like the data present itself as rows and columns via a QVector<QVariant> approach for each row. What would be the best way to adapt my current data structure? Should I rewrite it with all the data as a protected member in the base class of a type QVector<QVariant>?

FYI, I don't code as a profession. I'm just nutty enough to have this as a hobby after administering an enterprise sized Tivoli Storage Manager environment daily.

[wysota]

There is no simple answer to your question. The simplest solution I can think of is to represent the graph as a list of vertices and store the list of edges as a custom role of each item. You wouldn't even need to implement your own model from scratch - QStandardItemModel has all you need. Implementing a custom model storing a QVector (or a QList) of QVariant makes no sense as that's what the standard model does only in three dimensions.

Another approach would be to store the graph as a matrix of vertex connections (so you have a square matrix and matrix[ij]=true <=> there is a connection between nodes i and j).

If your graph has some specific properties, you can probably find a 3D representation of it as well...

[awhite1159]

Thanks Wysota. Having only worked with Qt for about 3 weeks, I have alot to learn. I am familiar with C++ but have always written console programs utilizing stdin stdout...

I'd really like to have my view accurately reflect the actual topology of the graph but that is too complex for me to take on with my experience. So I will find a way to represent it as a treeview. I'm currently adding Qt support code to my existing program and for now will keep the Qt data structure and actual data structure separate. I have been reading several books and anything I can get my hands on online.

One thing I am not real clear on is how the model handles data with different roles. Is it my responsibility to provide a container to maintain information for all roles? I want to add a decorative (Icon) and I am not sure if the functionality is inherited.

[wysota]

A model is only an interface to existing data structures. If you don't have such structures already, you can use a model that holds data internally, like QStandardItemModel does, but if you do have such structures, you can provide a model that will operate on them.

Roles are simply different pieces of data associated with some object. For instance if you had a decimal number, you could have a model with two roles - one returning the integral part of the number and another returning the decimal part. But both of them would operate on the same number. You could also implement the model in such a way that it returned red background for negative values and green background for positive ones. But again, the only data the model would operate upon would be the number itself - all the "other" data doesn't have to be stored anywhere - it can be generated from existing data if that is possible (or it can be static - the same value returned regardless of the contents of the data the model operates on). It is all performed by QAbstractItemModel::data() method. If you implement data() yourself, it is you who decides what gets returned in each case. If you use one of pre-made models, you have to stick with the features it has (or you can subclass the model and modify its behaviour by reimplementing virtual methods, as usual).

[awhite1159]

Got it. Thanks Wysota. I think what is spinning me around is getting used to the fact that the model manipulates the data structure in a way that can be understood by the view which can be completely separate from the underlying functional data structure and its pointers.

[wysota]

I think what is spinning me around is getting used to the fact that the model manipulates the data structure in a way that can be understood by the view which can be completely separate from the underlying functional data structure and its pointers.

It's exactly like that. Just don't limit yourself to thinking the model is only an interface for the view. You can use models directly - without a view.