Comparing Qt Widgets App under Gnome wayland using platform wayland-egl to xcb

myk321

Am not aware of something in the .pro to set the platform. Am planning to include a .desktop file to associate the application icon and to allow the Qt application to be added to the dock. The Exec command within the .desktop file allows the executable to be invoked with parameters.

Have logged the data visualisation issue under xcb here: https://bugreports.qt.io/browse/QTBUG-68263

Have switched to KDE plasma (no wayland) as my one man protest against the state of Qt CSD under Gnome.

mrjj

@myk321
Hi
You are not alone for wishing for CSD support.
I have seen 1 other person
https://bugreports.qt.io/browse/QTBUG-63969
https://forum.qt.io/topic/84359/how-to-have-my-qt-application-use-gnome-csd

myk321

Some additional insight over here: http://blog.qt.io/blog/2018/05/29/whats-new-in-qt-5-11-for-the-wayland-platform-plugin/#comment-1203650

mrjj

@myk321
Good news :)
When they iron out the gnome issues.

johanhelsing

That's quite a list of issues, I'll go through them one by one and write down what I know:

Under xcb, the data visualisation is not displayed and instead a black pane is displayed.

Should be reported as an xcb bug.

Under wayland-egl, the window decorations are different to xcb and look less platform native; on a HD screen the close button is too small to easily use.

Window decorations are drawn by the client on Wayland, except on compositors that opt-in to server side decorations. Gnome-shell has explicitly stated that they will do no such thing. Starting with Qt 5.11 the window decorations should scale when moving between high-dpi and non-high-dpi montiros. If they don't it might be that you haven't configured the scale factor for your screen. See devices and displays and scale or something along those lines in gnome-control-center.

Default font size are bigger under wayland-egl. The header in particular is strangly large under wayland-egl

It might be that gnome-shell is reporting the wrong physical size for your monitor on either wayland or xcb, which affects DPI and consequently point sized fonts. On Wayland you can run weston-info to see what kind of dimensions the compositor reports. You can also start your application like this env WAYLAND_DEBUG=1 ./myapp and look for a line saying something about the geometry of a wl_output. On xcb I have no idea.

Under wayland-egl, double clicking the window header when not maximised, does not maximise the window

That's something that should be easy to add, you can file a suggestion for it.

Under wayland-egl the maximise and minimise buttons, show and hide the data visualization graphic, not the window

That sounds really weird and you should file a bug for it. Ideally with a minimal example.

The wayland-egl window no longer starts in front

Sadly, clients have no control over stacking order on Wayland, it's left up to the compositor. Don't file a bug for this.

The wayland-egl window no longer starts maximised / at the requested size

I think this should be fixed in 5.11

On wayland-egl the following are written to the console on startup [...]

I don't know why you're seeing that. You should perhaps mention it in the reports you create.

Under wayland-egl, under gnome, docking the window on the left or right side of the screen (by dragging the header to the side of the screen) does not cause the window to dock instead the window remains its previous size

Fixed in 5.11

Unexpected wl_surface.enter received for output with id: 6 screen name: "Screen4" screen model: "0x040a"

This probably just means the compositor is misbehaving slightly, it shouldn't be a problem (we might remove that warning or only show it in a logging category).

qt.qpa.wayland: Wayland does not support QWindow::requestActivate()

This means your window tried to grab focus in the compositor, which is not allowed in wayland. Don't create a bug for it, there's nothing we can do.

mrjj

Hi
Super write up.
And welcome to the forums ;)

johanhelsing

@mrjj: Thanks :) It's easier to get my attention if you file bugs, though. And remember to add the wayland component to the issue.

@myk321: Not sure how notifications work here... Anyway, I answered your questions in my previous post.

@vithom:

when a window is displayed, its startup position is always in the upper left corner, with the title bar hidden by the gnome's desktop bar (with hour, "activity" menu, etc.) and sometimes its size or its position is suddenly changed.

I'm pretty sure this is a gnome-shell issue, I don't see it on other compositors. Trying to get a response from gnome-shell devs now: https://gitlab.gnome.org/GNOME/gnome-shell/issues/321

Is it possible to force the default platform to be xcb with an option in the .pro file for exemple ?

Sadly, we in the Qt Wayland team didn't know that Wayland was suddenly set as default when XDG_SESSION_TYPE was set. That totally went under our radar, and we've been working under the assumption that Wayland still wasn't the default in gnome-shell wayland sessions.

If you unset XDG_SESSION_TYPE, you should get xcb instead of wayland, i.e. do something like this in your main() (untested):

if (qgetenv("XDG_SESSION_TYPE") == QByteArrayLiteral("wayland")) {
    qWarning() << "Warning: disregarding XDG_SESSION_TYPE=wayland";
    qWarning() << "To use wayland anyway, please set QT_QPA_PLATFORM=wayland";
    qunsetenv("XDG_SESSION_TYPE");
}

EDIT: fixed typos in code.

myk321

The issue with data visualisation being displayed as a blank panel under xwayland is logged here: https://bugreports.qt.io/browse/QTBUG-68263
and here: https://bugs.freedesktop.org/show_bug.cgi?id=106757

The issue with the minimise button minimising the data visualisation, but not the window is now logged here: https://bugreports.qt.io/browse/QTBUG-68576

The issue with the default font size not being set under wayland is now logged here: https://bugreports.qt.io/browse/QTBUG-68577

The suggestion to enable double-click to maximise and restore window size is logged here: https://bugreports.qt.io/browse/QTBUG-68578

The issue with the error logs on application startup is now logged here: https://bugreports.qt.io/browse/QTBUG-68579

Johan, I understand that CSD is a quagmire, but we'd like to understand Qt direction so we can plan accordingly. I surmise from your comment above, that Qt's position on wayland CSD is to support SSD if its available (e.g. under KDE Wayland) and if SSD is not available to fall-back to a generic "Qt Default Window" (e.g. under Gnome-shell), which will look something like the window we see today under Qt 5.11 ie. blue title bar, black text, maximise, minimise and close right aligned. Is this a fair statement of Qt's direction? or it more a case that the official Qt position on wayland CSD has not yet been decided? I really don't mean to put you in a corner here, so if you'd rather someone else from Qt answer, or that you let us know a time-frame when this will be made know, also completely fine.

johanhelsing

@myk321 : Thanks for reporting!

Btw, you should be able to work around the font size issue by setting QT_WAYLAND_FORCE_DPI=96.

My opinion on the the future for CSD/SSD is that compositors that wish to draw decorations should be able to.
We will implement support for xdg-decoration when/if that gets merged into wayland-protocols, but it's still being reviewed atm.

I'm not opposed to implementing KDE's server decoration protocol either, but I'm also not going to write the patch for that myself. If I remember correctly. its license is also incompatible with Qt, but that's perhaps possible to solve if someone asks the authors to relicense it.

About the current decorations: I think they are very ugly and would like the default style to look nicer. I'm not sure when or even if I have the time to work on it, though. There were people outside The Qt Company that started looking at it, but I haven't heard anything in a while, so not sure what happened.

myk321

@johanhelsing - great, thank-you!

I've added a couple of addition wayland specific defects earlier today, including:
QTBUG-68599 - Unable to Drop when doing Drag n Drop under Wayland
QTBUG-68601 - Qt Applications Not Show under Wayland Gnome Activities Overview
QTBUG-68602 - Qt Applications Crashes Wayland Gnome Shell

As a suggestion: for Eclipse to help organise the wayland related defects on bugzilla, we created a umbrella "Improve Eclipse under Wayland" defect and then linked the individual point defects as depedencies to the umbrella defect. Having this umbrella defect made it somewhat easier to check what had already logged and what what still needed to be fixed. I see on the Qt Bug Reports site there is a concept of a sub-task (not sure if this works the same as dependency). Anyway, I've tagged each defect with 'Wayland', but please let us/me know if there is anything else I/we can do to make this easier to manage.

vithom

@johanhelsing said in Comparing Qt Widgets App under Gnome wayland using platform wayland-egl to xcb:

@vithom:

If you unset XDG_SESSION_TYPE, you should get xcb instead of wayland, i.e. do something like this in your main() (untested):
if (qgetenv("XDG_SESSION_TYPE") == QByteArrayLiteral("wayland")) {
    qwarning() << "Warning: disregarding XDG_SESSION_TYPE=wayland";
    qwarning() << "To use wayland anyway, please set QT_QPA_PLATFORM=wayland";
    qunsetenv("XDG_SESSION_TYPE");
}

Thanks for this solution, it works perfectly (just with qWarning() instead of qwarning() )

johanhelsing

Due to all the problems on gnome shell, we will probably unset Qt Wayland as the default in Qt 5.11.1 (and use xcb instead). If we get the serious bugs fixed, we will consider switching back to Wayland in Qt 5.12, though. Relevant patch: https://codereview.qt-project.org/#/c/231227/

I also created an umbrella task to cover things that should be fixed before we can switch the default back to Wayland: https://bugreports.qt.io/browse/QTBUG-68619

So unless you know your users are going to stay on 5.11.0 and not upgrade to 5.11.1 for a long time, you shouldn't need to apply the workaround I posted earlier.

myk321

Some more insight into further improvements for Qt6 under Wayland detailed here: https://bugreports.qt.io/browse/QTBUG-68847

johanhelsing

@myk321 : Note that that task is only about the stuff we can't easily do in minor releases. I.e. removing stuff, changing behavior, renaming imports.

Most of the bug fixes, improvements and new features will be done in 5.x releases in years to come.

myk321

https://www.phoronix.com/scan.php?page=news_item&px=Wayland-Protocols-1.15

Seems that the XDG extension is progressing into Wayland 1.15 - fingers cross that Gnome supports the extension!

myk321

Looks like there are some exciting improvements in Qt 5.12 (http://wiki.qt.io/New_Features_in_Qt_5.12), including:

Added support for xdg-shell stable (and deprecated unstable v5).
Made the default window decorations look nicer.
Added support for the Wayland extensions: xdg-decoration-unstable-v1, xdg-output-unstable-v1.

myk321

Default CSD on Qt 5.12 on Gnome 3.28, looking much better - funny colours and font sizes are gone :-)
Have logged:
QTBUG-70971: Mouse pointer increases in size when over a Qt Wayland Gnome window
0_1538787277958_Wayland Big mouse pointer.png

myk321

Have played about some more with Qt 5.12 Beta 4 under Fedora 29, KDE 5.13.5 (KDE Frameworks 5.51) and Gnome 3.30.2 and have opened:
Issue 1: No Window Decorations Under KDE Wayland (https://bugreports.qt.io/browse/QTBUG-71720)
Issue 2: Data Visualisation broken under Wayland (https://bugreports.qt.io/browse/QTBUG-71721)

Happily the issue that I had reported previously (https://bugs.freedesktop.org/show_bug.cgi?id=106757 and https://bugreports.qt.io/browse/QTBUG-68263), where the surface example did work under XWayland, is now resolved, althought it does display a bunch of messafe logs in the form:
qt.glx: qglx_findConfig: Failed to finding matching FBConfig (8 8 8 0)
qt.glx: qglx_findConfig: Failed to finding matching FBConfig (1 8 8 0)
qt.glx: qglx_findConfig: Failed to finding matching FBConfig (1 1 8 0)
So I've closed this issue noting that it appears resolved by Mesa 18.2.4.