From item based widgets to model/view

[timom]

Hi,

I could really use some help and general guidelines on how a complex hierarchical data model should be implemented using QAbstractItemModel interface (+ proxy models?) for several different views. The current solution that we have is implemented using item based classes (QTreeWidget, QListWidget mainly). The data model is separate from the widgets and implemented using standard c++ classes, containers etc. Qt widgets are used to visualize different parts of the model, for example a QTreeWidget is used to visualize the main hierarchy and when users selects an item there another tree widget visualizes the more detailed view from that item on and so on. There are tens different view on different levels of the data model. Synchronization between data model and item based widgets is made using identifiers and/or pointers that are stored to items (for example QTreeWidgetItem) as data (item->setData(0, id, Qt::UserRole)) and so one..

However, the trend seems to be away from the item based widgets (or has been that for a while now) and the future Qt versions are relying more and more to model/view approach (QtQuick + item models).

I'm a bit lost with Qt's model/view framework here... Would it be a good idea to describe the whole data model with one QAbstractItemModel interface and then use several proxy models to filter data for specific views or should we have several QAbstractItemModel based models in the first place... The Qt documentation is not very clear here - all the examples are for really small and simple data sets.

Any recommendations and/or pointers would be more than welcome!

Thanks,
- Timo

[pkj]

One big tree describing all your objects sure presents a fanciful idea, especially the ease with which most of the views can be ready almost instantly thanks to proxy model. However it becomes increasingly difficult to make a tree model for different object types. See, making a model for a type QList<ObjectType1> is not that difficult. Now if your objecttype1 has objecttype2 which is to be a child of a particular objecttype1, you can go ahead use the facilities of QObject and make objecttype2 child of objecttype1 or implement something like that yourself or create another node wrapper class which essentially goes ahead and dissects type of object and helps you with the index() and parent() functions.
With the growing objectypes classes, managing this node class becomes increasingly messy. And difficult. Moreover you cannot envisage the whole program beforehand. Later, it will become a head-ache when a new type comes in.
Having said that, it is better to have that object tree as big as possible, according to my opinion. The various classes generally interact with each other. Even if your data is outside your classes, and you interact directly with them, models need to be told with anything you changed. I wish there was a straight and correct answer to your question. I wish I knew it too.

[timom]

Thanks for your input! I know that there are no easy solutions for complex problems.. I guess what I'm looking for is some sort of "best practices" for Qt model/view for large/complex data models. Like said earlier, the Qt documentation and examples are very very limited.

Any idea how the whole model/view framework is going to develop in the near future? There's been a lot of talk how it's over engineered and complex and should be re-designed and simplified...