On 6/15/2022 3:11 PM, Ralf Van Bogaert wrote:
I'm really stuck with this.
Can anyone help?
It's doubtful you will get much in the way of answers about Qt desktop
questions. As to why, read this thread.
Most have abandoned Qt on the desktop. If you have access to a Toradex
development board you can kind of get started down the path here:
The plug-in for VSCode has options for QML and Widget creation. I'm not
running Wayland on anything other than embedded systems. Even on
them,*no matter what library I'm using, Elements, NanoGUI, etc. I never
have to reach into anything Wayland function wise*. The entire purpose
of a high (or at least higher) level library is to hide such things.
My gut tells me that, if you are using a .PRO file you are missing some
Qt + values. Getting some Toradex hardware and going through some
examples there will help you a lot. Most of the Toradex documentation
pages are circular. What I mean is you start reading one and it will
have at least one, usually half a dozen "read this first" links. After
about seven "read this first" links you find you are right back to the
page you started on.
The default TorizonCore stuff runs a Wayland desktop within a Docker
container. You can run standard X11 desktop application within other
Docker containers because Wayland has an X11 client. Depending on who
wrote the client and who built the OS, the quality of the clients range
from Rock Star to piss poor.
What I suspect is happening is that you are building an X11 application
despite what you believe.
I don't remember the name of the function, but there is a function in Qt
to force the choice of a backend/display engine. Back when my embedded
customers used Qt we used to have to use it a lot because the selection
logic which chose the graphics backend didn't always work well.
What I recommend is that you locate a full size Verdin dev board and one
of the Verdin imx8 modules because that combination works well for this
journey. I went down it myself. Not to get Qt to work with Wayland, but
to get everything else to work with Wayland.
There's a whole lot of Wayland configuration you need to know about and
won't be able to control on any desktop running Wayland. You can direct
control it in this type of embedded environment.
You need to see how the VSCode plug-in generates project files for a
"Hello World!" window with a button. Test it out. Then start from that
point, not trying to reverse engineer some QML thing.
*With a high(er) level library you should remain oblivious to the
underlying display engine.* It could be Vulkan, X11, Wayland,
Freds-new-engine-from-Thursday and your application should not care.
Your project configuration file, be it Cmake or .PRO is where this
decision should be contained. If Qt is "guessing wrong" you may need to
look up the function that forces engine choice and use it. Sorry, don't
remember off top of my head or I could point you to the blog post I
wrote about it many years ago. Qt is probably guessing wrong because
Wayland isn't well implemented on __any__ desktop yet. To understand
that statement you need to go the embedded route I have sent you down.
Qt has some issues/oddities on Wayland.
If you are unable to go the embedded route for your education, you might
want to scour scintilla-interest for the Wayland messages and see if any
of the editors having the issue are using C++ and widgets. I didn't
follow all of those message threads. I just know something got "fixed"
and some of the editors might still be using C++ with Qt. Most of those
editors are OpenSource so you could look at the project configuration
files to sus out what you need. You could choose to build one and step
through with the debugger as it starts.
Sorry, not a one & done answer, but this is a journey a person must go
on. Wayland is being forced on us and it is not yet stable, at least on
Roland Hughes, President
Interest mailing list