QT 5.8, what is the proper way to deal with data associated with visual elements?

Stoke

Hello, I have the following situation:

I've created a gui which has a TreeWidget which may have several top level items, and those top level items correspond to a list of sub items (that don't go any further than that).

I've been attempting to add associated buttons and gui objects to each of the lowest level tree widget items via TreeWidget.setItemWidget(item, column, widget). Once the user clicks the button I want to load on a seprate container widget adjacent to the TreeWidget container, fields for the user to put in. I've been able to load in gui elements dynamically and fields, but I came across a design problem.

Essentially, in the separate field window next to the tree window, the user will enter in data and I want it to be associated with the item that held the button to load the format in the first place (there's a button for them to save). I've seen setData for QTreeWidgetItems but I've never used Qvariants and I don't understand why I would ever use them, especially with known types. I've considered instead using a separate QList to hold my data, but shouldn't the data be associated with the tree items directly instead? With the separate QList method I have to associate the data via connect(... QObject::destroyed) and other signals. What is the proper method of associating arbitrary data of homogeneous type with elements in the gui? Should I be creating custom widgets/classes to represent both the visual element and the non-display data associated with it?

currently I'm using JSON to serialize creation of gui elements and saving the data inside the associated fields, but not QJson as it seems to be missing quite a bit and doesn't appear to be very easy to work with considering the sparse documentation of it. I've been using nlohmann json.hpp instead.

SGaist

Hi,

In that case, shouldn't you rather use a custom model with a QTreeView ? That way you'd be able to store all the data you want in one place.

Stoke

@SGaist said in QT 5.8, what is the proper way to deal with data associated with visual elements?:

Hi,

In that case, shouldn't you rather use a custom model with a QTreeView ? That way you'd be able to store all the data you want in one place.

Ok, I looked at this link before I decided to reply. Using model view instead of item based widgets seems to be the way to go. I've never used QT models and views. There's an example here that talks about how to create a custom treemodel, though in my example I know what types I want to use for the tree (so no q variants I guess). Would I make a model like this to set as the model for the tree view?

Should I use model view to represent the non tree portion half of the gui that generates fields for configuration input at runtime (why or why not)? If so how would I create a view for a custom structure? Its a line edit, a combo box and a scroll area, whose number of fields change at runtime (depending on the combo box value).

I saw in the model view programming page a section talking about the possibility of separating the data from the model itself, how would I accomplish something like that/would it be beneficial to do so? The tree model tutorial I listed states that this is outside the scope of the tutorial.

SGaist

If you have a custom data structure, say a list of a custom struct. Then the idea is that the model will act as a wrapper to show what you want from your struct elements. That's the idea of data outside of the model.

As for your editor it really depends on what would make more sense in your application. You could also have a side widget that you show when you click on one of the leafs.

Stoke

@SGaist said in QT 5.8, what is the proper way to deal with data associated with visual elements?:

If you have a custom data structure, say a list of a custom struct. Then the idea is that the model will act as a wrapper to show what you want from your struct elements. That's the idea of data outside of the model.

Ok, I realized that the treemodel example actually does have seperation between data and model, so that isn't an issue. When do you know when to implement a model view paradigm versus just item?

@SGaist said in QT 5.8, what is the proper way to deal with data associated with visual elements?:

As for your editor it really depends on what would make more sense in your application. You could also have a side widget that you show when you click on one of the leafs.

Currently I make the other config editor part a widget like you said, but I don't know "what makes more sense" for may application or how to reason about that. How do figure out what to use (in a general case)?

SGaist

Do you mean QTreeWidget VS QTreeView + custom model ? Usually people start with the former for ease of use then goes with the later because of better performance and control about the data structure.

"What makes more sense" boils down to how the design fits. You should take the time to do some drawings and GUI testing with a person that will use your application.

Stoke

Ok, I've learned way more about how model view works and how to implement AbstractItemModel methods, and have a new more specific question about how to make a specific type of model work with a tree view, which I'll ask in a separate question at a later date. I'm marking this as accepted, I didn't know what I didn't know until you answered. Thanks!

mrjj

@Stoke
Hi just to be sure u saw this example
http://doc.qt.io/qt-5/qtwidgets-itemviews-editabletreemodel-example.html