On 6/15/2022 3:11 PM, Ralf Van Bogaert wrote:
Hi guys,

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.

Bottom line.

*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 the desktop.

Roland Hughes, President
Logikal Solutions

Interest mailing list

Reply via email to