Comparing Qt Widgets App under Gnome wayland using platform wayland-egl to xcb
-
@mrjj: Thanks :) It's easier to get my attention if you file bugs, though. And remember to add the
waylandcomponent to the issue.@myk321: Not sure how notifications work here... Anyway, I answered your questions in my previous post.
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_TYPEwas 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.
-
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=106757The 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.
-
@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.
-
@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 ShellAs 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.
-
@johanhelsing said in Comparing Qt Widgets App under Gnome wayland using platform wayland-egl to xcb:
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() )
-
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.
-
Some more insight into further improvements for Qt6 under Wayland detailed here: https://bugreports.qt.io/browse/QTBUG-68847
-
@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.
-
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!
-
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.
-
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.
