Using a tree widget to display a list of model objects

[xtal256]

Ok, can anyone tell me when i should use Q*View over Q*Widget and what are the advantages/disadvantages?
What i have done so far with QTreeWidgets or QTableWidgets is to create the widget items and populate them with data from my model object/s. And i could continue to do so here, extending QTreeWidget and maybe QTreeWidgetItem to store a pointer to it's associated model and populating the UI with data from the model. But i get the impression that QTreeView gives more flexibility and power to do complex stuff like this.

[jeanremi]

The forum is not very quick in replying, is it? ;-)

Anyway, I asked a similar question on one of my threads and I was told by Squidge (expert member here) that the idea is to create a container widget which will contain your subclassed/derived widget, you can do custom drawing in your derived paint functions. That's my understanding for this kind of complex UI in Qt. Sorry if it misleads you

I'm about to start my custom timeline control which will effectively be the container control and it will contain a custom qtreewidget, custom ruler, custom chart control (for tracks) and a custom moving thumb to achieve my goal.

There are no tutorial that shows me how to do this, so I'm heading myself into it from scratch (but yes some Qt examples will teach me how to code into the paint functions and stuff). When successful, I will probably post it as a tutorial.

Best of luck.

Jean

[joyer83]

Ok, can anyone tell me when i should use Q*View over Q*Widget and what are the advantages/disadvantages?
What i have done so far with QTreeWidgets or QTableWidgets is to create the widget items and populate them with data from my model object/s. And i could continue to do so here, extending QTreeWidget and maybe QTreeWidgetItem to store a pointer to it's associated model and populating the UI with data from the model. But i get the impression that QTreeView gives more flexibility and power to do complex stuff like this.

Use QTreeWidget when you have just some data that doesn't change. If the content can change then it is easier to use the View - Model system (in my opinion). Easiest way to start is to create a QTreeView and a QStandardItemModel and give the model to the view with QAbstractItemView::setModel(). When you modify the model the view will update itself automatically.
If you need to filter out items from the view, you can use QSortFilterProxyModel for that. The proxy is given to the QTreeView using the setModel() method above. The model which the proxy listens for is given with QAbstractProxyModel::setSourceModel().

[xtal256]

Thanks for the tips joyer83.

One thing i am still not sure about is what the "model" actually is. I have created classes to model the data in the system (OS windows in my case), but i get the feeling that the model objects used with views (QStandardItemModel) are something different. I will check out the documentation and examples and hope that clarifies things for me.

[xtal256]

Ok, i think i now understand the purpose of the "model". I was thinking that i needed to use my objects (Window, WindowMessage, etc) as the model for the QTreeView or QListView, where each item would have a model. But i now see that views have a model to represent the entire data structure. So i guess this means that i would subclass one of Qt's model classes to hold the list of messages. Is this right? Since i already store the messages in a list somewhere, how will this model object differ from the QList i already have?

If you don'tknow what i'm talking about, you can download the latest source code from here to see how i'm currently doing thinks.

[joyer83]

One thing you should notice first is that you wanted to represent the data as a tree while you data internally is stored as a list. While implementing something that can map between tree like structure and list like structure on-fly is not impossible, but it will not be easy either.

You have two choices, would you like to store WindowMessage's data into Qt's model or do you want to keep on using the QList?

For first choice, You could use QStandardItemModel, no need to subclass any model classes. Adding new messages would work something like this:

QStandardItem *messageItem = new QStandardItem( messageName );
QStandardItem *lparamItem = new QStandardItem( lParam );
QStandardItem *wparamItem = new QStandardItem( wParam );
model->invisibleRootItem()->appendRow( messageItem );
messageItem->appendRow( lparamItem );
messageItem->appendRow( wparamItem );

QStandardItem *messageItem = new QStandardItem( messageName );
QStandardItem *lparamItem = new QStandardItem( lParam );
QStandardItem *wparamItem = new QStandardItem( wParam );
model->invisibleRootItem()->appendRow( messageItem );
messageItem->appendRow( lparamItem );
messageItem->appendRow( wparamItem );

To copy to clipboard, switch view to plain text mode 

For second choice, you would subclass QAbstractItemModel and use it as an adapter which internally reads the QList and at same time provides an interface (QAbstractItemModel) which the QTreeView can access. In this choice you need to implement the list-tree mapping. You need to also remember to notify the model whenever the QList is being modified, otherwise the QTreeView will not update.