There are 3 primary rules when it comes to Qt develop.
-
Never use QML for anything
-
Never use QML for anything
-
Never use QML for anything
Read the message thread started by Mark Gaiser here:
https://lists.qt-project.org/pipermail/interest/2022-February/thread.html
That’s just the latest in a loooong conversation about QML being a hand polished turd.
That’s an image from a lengthy blog post I wrote here.
In that post I was explaining to someone why they couldn’t get tables to work properly because when you create an object in the green C++ lane then pass it to the red QML lane QML and its VM now believe it owns it and is responsible for the life and death. QML is a neutered crippled creature that cannot do much so it hands it off to JavaScript and its VM. Now JavaScript firmly believes it controls the life and death of the object.
The application drunk drives across all three lanes and has random crashes due to garbage collection running in three different lanes at three different uncontrollable times.
That’s not your problem, but it kinda is.
You make the claim that the “default” environment is Wayland/Weston. - - - Not exactly true.
There is a Wayland/Weston compositor in the default TorizonCore. It has some X11 client capabilities. It’s the some that’s killing you.
Remember the three lanes and drunk driving from earlier? Well, they all determine which backend to use. When you pass -platform on the command line you force all 3 of them to use the same backend. When left to their own decision tree they don’t all arrive at the same place.
If memory serves it searches from the oldest/lowest forward. Depending on how your stuff was built one lane may find and love XCB. Another might find and prefer EGL.
The EGL support is far from complete in Wayland/Weston.
I strongly recommend you never consider Qt for anything going forward. The bug database is north of 5,000 and many of them are old enough to get a driver’s license in America. Qt 6 is piling bugs on by the train load.
For board verification we went with NanoGUI.
For actual product they are using Elements.
Both produce light clean UIs. Both have to be built and run in a pure Bullseye Docker Container.
You can make almost anything that uses pure X11 work inside of a Bullseye Docker Container. What you can’t do, at least I never could, is get the mouse. Touch input is just fine, but the mouse cannot be seen.
From inside a container you also cannot control screen position. If you are writing a full screen touch-screen app this isn’t an issue.
You can follow some of this discussion with these two threads on here.
Assuming you are determined to stick with Qt despite it being a really broken platform right now, you need to actually read this:
Don’t just glance at it, actually read it. You are assuming the plugin you need to use actually got built. That’s not a safe assumption. You are probably going to have to do your own Yocto build unless you can find a way to wedge a custom Qt from source build into TorizonCore Builder.
This plugin system that Qt has is a massive Achilles Heel. Just because something runs fine on your Ubuntu laptop doesn’t mean anything. That environment builds the XCB plugin by default. God only knows what got built with the default TorizonCore build. Apparently the XCB plugin did because when you force XCB with -platform your application “kinda works.”
I suspect at least part of your application is trying to use EGL on target and that ain’t going to work. I couldn’t make it work for either NanoGUI or Elements and those are comparatively simple libraries.
Once you are done reading the first Qt plugin link, you can read the Wayland specific one.
If you don’t read the other one first, this one isn’t going to help you.
If you want a great big has everything UI library, last I checked, the TorizonCore repos included wxWidgets. It supports Wayland. You can use CodeBlocks for the IDE unless there is a wxWidgets plugin for VSCode.
Getting something to run “native” on the default TorizonCore with Wayland/Weston running is a real PITA. Not something anyone should attempt on their first try if they aren’t used to embedded systems work.
This is why they push Docker Containers as the main development method. As long as you don’t need the mouse, you can make most things work in a Docker container.
Here is a wee bit more Qt Wayland documentation for you.
Wayland also introduces an awful lot of bugs/problems.
https://bugzilla.redhat.com/show_bug.cgi?id=1773650
Enough that they had to introduce a fallback list.
https://bodhi.fedoraproject.org/updates/FEDORA-2019-690a29587a
If you are using touch and don’t mind using containers, you can make very professional looking applications using Elements. You can make good simple applications with NanoGUI. You can make massive applications with wxWidgets.
Just don’t make the mistake of believing that because you can get something simple using Qt/QML up and running on Ubuntu it ought to be a cake walk on an embedded target. That’s not going to be true. Ubuntu still using X11 so everything “just works.” Very little actually “just works” with Wayland/Weston.