The combination QQuickview and QWidget::createWindowContainer() not working with wayland

Technical Support
, , , , ,
1

Hi all,

I am trying to integrate Qt Widgets(C++) and QML elements with Colibri IMX8QXP and Iris 2.0 carrier board as per the discussion : https://www.ics.com/blog/combining-qt-widgets-and-qml-qwidgetcreatewindowcontainer
Note:- I created the Image and SDK with Yocto Open Embedded procedure : Build a Reference Image with Yocto Project/OpenEmbedded | Toradex Developer Center

The example shown in the above link is:

mainwindow.cpp

#include
#include “mainwindow.h”
#include “ui_mainwindow.h”

MainWindow::MainWindow(QWidget *parent) :
QMainWindow(parent),
ui(new Ui::MainWindow)
{
ui->setupUi(this);
connect(ui->pushButton, SIGNAL(clicked()), qApp, SLOT(quit()));

QQuickView *view = new QQuickView();
QWidget *container = QWidget::createWindowContainer(view, this);
container->setMinimumSize(200, 200);
container->setMaximumSize(200, 200);
container->setFocusPolicy(Qt::TabFocus);
view->setSource(QUrl("qrc:/main.qml"));
//view->setSource(QUrl("main.qml"));
ui->verticalLayout->addWidget(container);

}

MainWindow::~MainWindow()
{
delete ui;
}

main.qml

import QtQuick 2.1

Rectangle {
id: rectangle
color: “red”
width: 200
height: 200

Text {
    id: text
    text: "This is QML code.\n(Click to pause)"
    font.pointSize: 14
    anchors.centerIn: parent
    PropertyAnimation {
        id: animation
        target: text
        property: "rotation"
        from: 0; to: 360; duration: 5000
        loops: Animation.Infinite
    }
}
MouseArea {
    anchors.fill: parent
    onClicked: animation.paused ? animation.resume() : animation.pause()
}
Component.onCompleted: animation.start()

}

I built this application and deployed in the target IMX8QXP system. When I run it with xcb with the following command, it is working fine.

root@colibri-imx8x-06855490:~# ./QMLtoQT --platform xcb

But the QML portion is not displayed when I run it with the default wayland platform:
root@colibri-imx8x-06855490:~# ./QMLtoQT

I think the combination of QQuickview and QWidget::createWindowContainer() is a very basic implementation for adding qml elements into Qt Widgets application. But this is not running with the default wayland platform. Is there any work around to solve this issue?

Thanks in advance for the help.

Sajeevan.K

2

Hi,

There is an update for the same issue.

I further tested Qt QML integration and observed the following:
The alternative to the combination of QQuickView and QWidget::createWindowContainer() is - QQuickWidget

with QQuickWidget

QQuickWidget *wid = new QQuickWidget();
wid->setSource(QUrl(“qrc:/main.qml”));
wid->setAttribute(Qt::WA_AlwaysStackOnTop);
wid->setClearColor(Qt::transparent);
ui->verticalLayout->addWidget(wid);

I tested the same code replacing QQuickview portion with the above QQuickWidget portion in mainwindow.cpp.

This time, the program is running in wayland platform also. But there is heavy flickering(no flickering with xcb platform), whenever there is a movement in the qml portion. When the animation or movement is stopped there is no flickering.

In both of these cases, the application is working finely in my Ubuntu Laptop.
So I doubt some issues with my image/sdk build. My Qtbase config summary is attached for reference.

~/oe-core-IMX8/build/tmp/work/x86_64-nativesdk-tdxsdk-linux/nativesdk-qtbase/5.14.2+gitAUTOINC+3a6d8df521-r0/build/config.summary is attached.
config.summary_qtbase (6.1 KB)

How can I ensure that a basic qml/qt quick application with some animation(movement) is working in Colibri IMX8QXP+Iris 2.0 platform without any flickering.

Can anybody suggest some proven example applications.
Sajeevan.K

3

There are 3 primary rules when it comes to Qt develop.

  1. Never use QML for anything

  2. Never use QML for anything

  3. 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.

qml-flow-2
qml-flow-21004×711 34.2 KB

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.

1 Like
4

Hi seasoned_geek,
Thank You very much for providing a comprehensive guidance on the topic. Now, I remember Yocto/oe build was not the main development method, suggested by Toradex for Colibri IMX8QXP. It was Torizon+Docker Container.

I was choosing Yocto/oe build, since I used it for developing applications for Colibri IMX7D. And I thought that I can reuse some of the code.
So I need to think about shifting to Torizon+Docker Container method. Hope I would get further guidance on request from this community.
Thanks for the guidance,
Sajeevan.K