Hello,
I have several qt software installed on my fedora 35 that have visual bugs/artefacts and not working well at all. These include digiKam or TeXstudio, both from the official fedora rpm repos. Where could this issue come from?
The bugs mainly reside on 2 things
The menu bar is broken
When dragging around the window some weird artefacting can happen
Here some of the errors I get with digiKam:
QSocketNotifier: Can only be used with threads started with QThread
kf.xmlgui: Unhandled container to remove : Digikam::DigikamApp
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: setGrabPopup called with a parent, QtWaylandClient::QWaylandXdgSurface(0x55bffca4d7d0) which does not match the current topmost grabbing popup, QtWaylandClient::QWaylandXdgSurface(0x55bffd4f61d0) According to the xdg-shell protocol, this is not allowed. The wayland QPA plugin is currently handling it by setting the parent to the topmost grabbing popup. Note, however, that this may cause positioning errors and popups closing unxpectedly because xdg-shell mandate that child popups close before parents
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: setGrabPopup called with a parent, QtWaylandClient::QWaylandXdgSurface(0x55bffca4d7d0) which does not match the current topmost grabbing popup, QtWaylandClient::QWaylandXdgSurface(0x55bfff0199a0) According to the xdg-shell protocol, this is not allowed. The wayland QPA plugin is currently handling it by setting the parent to the topmost grabbing popup. Note, however, that this may cause positioning errors and popups closing unxpectedly because xdg-shell mandate that child popups close before parents
Has anyone an idea or a bugfix why this happend?
Thanks!
EDIT: even with the flatpak version of digikam (flathub) the dark theme is not recognised and the menu bar broken
Yeah, it appears that even after all this time, a lot of Qt is not-ready-for-wayland-primetime unfortunately. Not so much Qt itself (though, at least with Qt5, maybe some of that too), but apps that are written for earlier Qt-on-X and need code updates to be fully Wayland-compatible.
Note that not all (or maybe not even any) of those are errors, they’re merely log messages. Some of them (particularly “Wayland does not support QWindow::requestActivate” which has gotten a lot of attention), the Qt devs have already effectively labeled WONTFIX as it’s merely Qt reporting that an action taken in the code isn’t possible under Wayland. They can’t make it possible, and since the action (grabbing window focus) is stil useful under Xorg, they’re also unlikely to remove the action itself. They could hide the message, I suppose, but it’s still valid. The statement on the requestActivate() message in particular comes down to, “Just ignore it”.
You’re also experiencing problems with some applications, so it’s natural to scrutinize any messages being output by the code for clues as to why, but not all messages are necessarily related to the issues, nor are they necessarily indications that anything is wrong. Some of them may be, but others may simply be irrelevant.
(The QSocketNotifier message, also — even qtdiag triggers that one at the start of each run, under Wayland, but it still works fine so clearly the message doesn’t have any major impact on functionality.)
One thing you can try — and this works on any Qt software — is starting the application from the command line with the argument -platform xcb added on. That’ll switch from the libqwayland platform plugin that’s the default when running with XDG_SESSION_TYPE=wayland, back to the old libqxcb platform plugin from the Xorg days running under Xwayland. …I was going to suggest making sure you have xorg-x11-server-Xwayland installed first, but it looks like it’s required by gnome-session-wayland-session so you can’t not have it installed already.
If that does solve things, you can make it the default for all Qt software by setting QT_QPA_PLUGIN=xcb in your user environment.
Thanks a lot for your detailed help!
So if I understand it correctly, those apps are not ready for wayland yet. Is the best solution to track the wayland issue upstream in their bug tracker in order to fix this issue in the future?
Well… maaaaybe. Certainly, if there are serious Wayland issues with any specific package, those should be brought up with the maintainers. But the issues may be largely beyond their control. As I said, with Qt5, there’s some extent to which Qt itself still comes up short.
I don’t know if you even noticed this, but if (for instance) digikam is running natively under Wayland, resizing the window by dragging an edge/corner is almost impossible — the drag targets are razor-thin. It’s hard to see how that would be the fault of digikam itself, but to some extent it must be because other Qt apps (VLC, for instance) aren’t affected the same way. It must come down to differences in how digikam and VLC construct their application windows. But the problem could live either in the digikam code itself, or in Qt code that digikam uses but VLC doesn’t (or vice versa). There almost certainly are still issues in the Qt5 code under libqwayland.
The Qt devs are pretty much exclusively focused on Qt6 now, so there’s a good chance any remaining issues won’t ever be fixed in Qt5. The safest bet, if you do have affected applications and using the xcb platform fixes them, is probably to just export QT_QPA_PLUGIN=xcb in your $HOME/.profile or similar, so that everything sticks with xcb for the immediate future. The whole question of native wayland support can be revisited when Qt6 has become the default Qt and most applications are using it.
