Design problem between choice of single or multiple C++ models
-
@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.
-
Ok, let's split the problem in the 3 components:
The model
You can subclass
QAbstractListModeland build your own but I suggest to useQStandardItemModelthrough theQAbstractItemModelinterface only (the easier way is to have something likeQAbstractItemModel* model = new QStandardItemModel.
Now you can useinsertRows/insertColumnsto add gauges andsetDatato 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
QStyledItemDelegatesubclass that will take care of painting a single gauge. The method you want to reimplement isQStyledItemDelegate::paint. From there you can useindex.data(role)to retrieve the data stored in the various roles of the model beforeThe View
This decides how the gauges are laid out you can use
QListView/QTableViewin the beginning and then subclass your own of you feel the need
An Alternative
Instead of the delegate+view approach you can use
QDataWidgetMapperhttp://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 -
@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.
@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
insertRoworremoveRowon the model at runtime to change the number of gauges -
Just an idea now.
I suggest to reconsider the data structure design. The software dependencies might become clearer also for your use case.
-
@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
insertRoworremoveRowon the model at runtime to change the number of gauges@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 . Yes, I may need to rethink the datastructure. But it is the best I can think of right now.
-
But it is the best I can think of right now.
Would you like to combine any more elements into specific classes?
-
@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.
@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
setSubEditorDatato pass the relevant parameters to the widget -
@elfring . No, each gauge would only have specific name, its unit and value. And the value would be updating each second.
-
@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 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
setSubEditorDatato pass the relevant parameters to the widget -
@VRonin . Could you please explain why the performance will be problem. What could cause that.
@milan said in Design problem between choice of single or multiple C++ models:
Could you please explain why the performance will be problem. What could cause that.
It's due to the way widgets are painter. Whatever the reason though you should ignore the performance issue, as it's (highly) unlikely you'd have tens of gauges, much less thousands of them.
-
@VRonin . Could you please explain why the performance will be problem. What could cause that.
@milan said in Design problem between choice of single or multiple C++ models:
Could you please explain why the performance will be problem
I'm not saying it will be a problem but it's certainly not optimised. You are mixing 2 UI frameworks one painted inside the other so it's only natural it won't be as performing as manual painting on a
QStyledItemDelegatesubclass -
@milan said in Design problem between choice of single or multiple C++ models:
Could you please explain why the performance will be problem. What could cause that.
It's due to the way widgets are painter. Whatever the reason though you should ignore the performance issue, as it's (highly) unlikely you'd have tens of gauges, much less thousands of them.
@kshegunov . There will be around 10-20 gauges i think in a tab, another tab will use same model's data and name to display in Qt Charts.
-
@milan said in Design problem between choice of single or multiple C++ models:
Could you please explain why the performance will be problem
I'm not saying it will be a problem but it's certainly not optimised. You are mixing 2 UI frameworks one painted inside the other so it's only natural it won't be as performing as manual painting on a
QStyledItemDelegatesubclass -
@VRonin. I did not like to use two UI frameworks, but I did not find nice gauge in Qt Widgets. But using QML for a desktop application, I find it not easy.
@milan said in Design problem between choice of single or multiple C++ models:
but I did not find nice gauge in Qt Widgets
At the end of the day it's an arch, 2 triangles, some tick lines and some text. It's not hard to paint manually and a "gauge" allows so much personalisation that it's hard to ship a generic pre-made widget that satisfies everyone
