Design problem between choice of single or multiple C++ models

milan

@elfring. Yes I have these problems. I do not also know which data structure could be suitable for this.
I am thinking of QList<QVariant>. The QList item of QVariant will again hold QList of QVariants. I do not know if this is appropriate solution.

VRonin

@milan said in Design problem between choice of single or multiple C++ models:

What i meant to say is each gauge will have different data, because it is fed by different data in the list.

So basically each element in the list should be represented by a circular gauge. I that correct? if so, how are the gauges arranged on the view (one under the other, in a grid, etc.)

milan

@VRonin . Yes, for testing, I am using horizontal layout now. Grid layout can be good option.

elfring

I am thinking of QList<QVariant>.

Are you using customised data models for your software application already?

I do not know if this is appropriate solution.

Which objects will you pass to the member function “setModel” of your views?

milan

@elfring. Yes, I am using QAbstractListModel now. But I do not know if QAbstractItemModel or QAbstractTableModel would be better choice?

I am not yet able to have working application yet. I think I need to pass Qvariantlist for each gauge because gauge will have name, value and unit. And all those parameters will come from the model.

elfring

I am using QAbstractListModel now.

Would you like to fiddle with any “tables” after the current list approach?

milan

@elfring. I got confused now with list based approach or table based approach as gauge should have few parameters coming from model namely, name, unit, and value.

elfring

few parameters coming from model namely, name, unit, and value.

Did you put these items into a specific class together?

VRonin

Ok, let's split the problem in the 3 components:

The model

You can subclass QAbstractListModel and build your own but I suggest to use QStandardItemModel through the QAbstractItemModel interface only (the easier way is to have something like QAbstractItemModel* model = new QStandardItemModel.
Now you can use insertRows/insertColumns to add gauges and setData to store in different roles all the data you need for the gauge (e.g. min, max, current value, tick distance, colour, etc.)

The delegate

This is a QStyledItemDelegate subclass that will take care of painting a single gauge. The method you want to reimplement is QStyledItemDelegate::paint. From there you can use index.data(role) to retrieve the data stored in the various roles of the model before

The View

This decides how the gauges are laid out you can use QListView/QTableView in the beginning and then subclass your own of you feel the need

An Alternative

Instead of the delegate+view approach you can use QDataWidgetMapper http://doc.qt.io/qt-5/qdatawidgetmapper.html to map data in a model directly in a widget. This is not the most efficient solution however as it duplicates the data and it's really designed to show a specific item (or a subset of items) from the model

milan

@elfring . No, not yet. I thought of QList<QVariantList>. The QVariantList would contain QVariants of QString(Name), QString(Unit), double/int (Value). Just an idea now.

elfring

Just an idea now.

I suggest to reconsider the data structure design. The software dependencies might become clearer also for your use case.

milan

@VRonin. In C++, we are not sure how many gauges will be in the window. The gauges will be added depending upon the parameters chosen by user in the UI. For example, if the user choses 5 parameters, there will be 5 gauges.

VRonin

@milan said in Design problem between choice of single or multiple C++ models:

For example, if the user choses 5 parameters, there will be 5 gauges.

You are free to call insertRow or removeRow on the model at runtime to change the number of gauges

milan

@elfring . Yes, I may need to rethink the datastructure. But it is the best I can think of right now.

milan

@VRonin. Okay, I can also give your idea a try. But what about the gauge parameters like Name, value, unit that is coming from the model. I also forget to add that gauge is Circular gauge from QtQuick2 extras used as quickwidget in QtWidget application.

elfring

But it is the best I can think of right now.

Would you like to combine any more elements into specific classes?

milan

@elfring . No, each gauge would only have specific name, its unit and value. And the value would be updating each second.

VRonin

@milan said in Design problem between choice of single or multiple C++ models:

But what about the gauge parameters like Name, value, unit that is coming from the model

@VRonin said in Design problem between choice of single or multiple C++ models:

setData to store in different roles all the data you need for the gauge (e.g. min, max, current value, tick distance, colour, etc.)

@VRonin said in Design problem between choice of single or multiple C++ models:

The method you want to reimplement is QStyledItemDelegate::paint. From there you can use index.data(role) to retrieve the data stored in the various roles of the model before

@milan said in Design problem between choice of single or multiple C++ models:

I also forget to add that gauge is Circular gauge from QtQuick2 extras used as quickwidget in QtWidget application

Ok, so performance is already out of the window, so you can use this template delegate to make the delegate part a lot easier. You just need to reimplement setSubEditorData to pass the relevant parameters to the widget

elfring

@milan said in Design problem between choice of single or multiple C++ models:

No, each gauge …

It seems then that you are using a widget with well-known properties.
Will you eventually pass the name to a label?

milan

@elfring. Yes, each gauge has to be identified. So the label text will be updated by the model.