Best strategy for implementing gui
-
Hi all,
I'm working on a embedded project where we want to display relatime position (gps) and velocity data, as well as other propulsion parameters. The data shall be presented to the user as graphical symbols and text on a touch screen. The appearance, number and position of some of the symbols will vary over time.
What is (in your opinion) the best strategy for the gui: using standard/custom QtWidgets or use QtQuick?
Best Regards,
Bubbas -
I'm sure, it depends whom you ask :-)
I would use standard/custom QWidgets, but I have not used QtQuick up to now.
If it must be a fancy UI, perhaps QtQuick is the better alternative.As you are talking about embedded, how performance / memory critical is it? This will also have impact on that decision.
-
Hi,
The application I'm working on shall run on an embedded machine with 256MB RAM and 1GB memory. The application as such is not safety critical (as in "human life depend on it") but the displayed data shall (among other things) be used for collision avoidance. Data shall be displayed in realtime (as in: data is continously fed from the backend to the gui at ~30 - 100 Hz).
As I understand it and as you mention above there are three possibilities:
- QtGraphicsFramework
- QtWidgets
- QtQuick
Now, is there a possibility to use a combination of the above? Specifically, is it possible to combine QtQuick and QtGraphicsFramework? e.g. use QtQuick for simpler things such as buttons, sliders, gauges etc. and use QtGraphicsFramework for displaying a map with position data, velocity vectors etc. handled by a custom c++ written mapengine?
Best Regards
Bubbas -
Hi Bubbas,
the techniques are combinable. But take care, you don't have to much memory (and therefore perhaps also not to much processor?).
Data update by more than 25 Hz is faster than a film which normally repeats 25 times / second :-) Depending on the amount of updatable data, this has a big impact. Do you have OpenGL available on your device?
Do you have graphics hardware on board? do you have to render in memory?
Take a look at the presentation from Devdays 2010 from Gunnar Sletta: "Performance: Do Graphics the Right Way":http://qt.nokia.com/developer/learning/online/talks/developerdays2010/tech-talks/performance-do-graphics-the-right-way
He showed many things about graphics performance, which might be your problem with update rates of more than 30 Hz.
-
I think I would approach this with plain QML for the simple elements. For any custom elements you may need to write these yourself in C++ using QDeclarativeItem subclasses. These custom elements can then be instantiated using QML.
There are some examples that ship with Qt that show how to do this.
-
Hi all,
The hardware we're using has hardware acceleration available and the processor runs at 600MHz. There is OpenGl support on the device.
The update rate of data is, as you say, a bit high for the gui. A better value would lie in the range of 25 to 60 Hz depending on the data.
If I were to go with QML there is a new issue: How well is QML adapted to show complex data? For example imagine a situation plot in polar coordinates with a number of "items" scattered around the plot, where each item is showing its position coordinates, velocity vector etc (e.g. some sort of "radarplot").
Or, should I use QGraphicsView/QGraphicsScene to create a dedicated widget for handling such complex ui components?
Bubbbas
-
You could create your custom items (the ones that show coords, velocity etc) directly in QML I think. Just bind the properties of the QML elements to your data source.
The trick will be to get your data source to set the properties at a sensible rate. How many such items need to be drawn and updated?
You may need to write a custom element in C++ for the radar plot axis/grid part. This can of course then be instantiated in your QML scene.
-
Hi,
The number of items on the plot may be as many as 200, where each item can display a number of "properties" such as position, velocity, name, etc etc. The number of displayed "properties" will of course depend on the "zoom" level.
All "data-related-logic" will be perfomed in c++, e.g. calculation of positions, velocities etc, etc.
Hmm...I think i have found the missing pice of information that I was looking for. I was worried about not getting the detail level needed if I composed the "radarplot" axis/gridfrom *.png files. But as you point out, I can create a custom element in C++ that inherits from QDeclarativeItem and creates the grid/plot stuff.
Does any one of you have any expericence in using QML for a scenario similar to the one described in this post?
Bubbas