a Question to strategy for c++ backends with large number of values
-
I need to think of a feasible strategy when I want to support many 1000 viualized in QML.
We will want to implement QT on an embedded device (control and measuring device) with iMX.9 CPU and embedded Linux on a HMI there. I am looking how to plan that from a SW side.
The system has about 5000 parameters (tunables) the customer can change, a couple of 100 values it measures the customer can see, all that localized in >10 languages. Tunables can be numerics and enums, but also more complicated structures where we need sort of input masks for them. Every value and tunable has a numerical identificator, let's call it an index. These indices are not contiguous. There is an internal bus in the system where the QML-connected backend can get all information of each tunable and value by index, like getting and setting data and getting description texts, number fomats, data type, enumeration texts, etc. (all in multiple languages).
The basic strategy would be that there is a frontend, in QML, maybe with say 500 to 1000 pages and all these shown variables and tunables are held in the backend and are exposed to QT as properties with setters and getters, there will be signals emitted when a value has changed and when the user changes a tunable there will be a setter to tell it to the backend.
This works when you have a small number of tunables/values, but if you have 5000 of them you need 5000 setters/getters etc. and that strikes me as a waste.
Is there a way to do that more intelligently? Is there a way that there we could define a QML element for a list of tunables, which are in QML referred only by their index?
So, in QML there is only a list of the indexes of the tunables given to this QML element as property or so, and then the element pulls for each index in the list from the backend the type (numeric, enum, structure), the values and texts and enums of this tunable and shows them.
In the main QML app there will then multiple (some 500) instances of this element, each one on one page, and each holding about 10 tunables. But there is only one backend "property" and the backend gets the index of each tunable it shall show and so knows which value and text and enum it shall request from the internal bus (from the main application) and push to the visualization.I looked into examples I found but my use case, large amounts of values, I could not find. Has anyone a feasible strategy there or can point me to a example for that?
-
@Veit
Without claiming to have fully understood your requirements, this sounds like a classic Model/View pattern, which is well-supported in Qt. The QAbstractItemModel class can handle complex and large models I believe, with data items communicated between model and view as QVariants.This: https://doc.qt.io/qt-6/qtquick-modelviewsdata-cppmodels.html describes how to mix QAbstractItemModel subclasses with QtQuick.
The design of the model subclass or subclasses would be the major task of course. Perhaps partition the back-end data with multiple QAbstractItemModel subclasses which abstract some of the backend data structures. The model-view interactions would involve only a few calls/signals.
-
@KenAppleby-0 Thanks for the hint (or encouragement). Your link was basically the first thing I looked at and followed up to a point. It uses the QAbstractiLst (or st. named similar). I was a little hampered there as Qt Creator, with which I followed the video, seems to be a little "brittle" as it suddenly stopped debugging for no reason and I cannot get it running again. But I will try to resurrect it ;)
-
@Veit
It's usually the debugger that causes the brittleness, not QtCreator. It can get frustrating at times. But don't let that put you off.The main documentation for the whole design pattern is here:
https://doc.qt.io/qt-6/model-view-programming.html
It uses QWidgets in the descriptions, but the previous link should show how to move it to QtQuick.
I have used this pattern and these classes in many applications and found it excellent, for some quite large models, though perhaps not with the structural complexity of the one you are dealing with.
I expect the simpler models implemented in the classes QAbstractListModel and QAbstractTableModel will not be sufficient for you and you will need to use QAbstractItemModel as a base. Maybe even have more than one model.
-
Is this for a "user" that needs an actual UI or is this for some "developer" type for tuning the system properties?
Does it need to run on device?
If this was on the desktop you could probably do this in excel with some VBA for the communication with the device (or your backend if the device talks to the backend server first)