-
Notifications
You must be signed in to change notification settings - Fork 437
Open
Labels
Description
https://bugs.kde.org/show_bug.cgi?id=372346#c3 says:
Wayland is a completely new graphics system. Nothing will run there unless the framework and/or application ports to that stack. For Qt, unless you ship the Wayland platform plugin, your application has no chance to run.
I have a hard time believing that given that Fedora already has switched to Wayland and apps apparently are still running there but if true, then linuxdeployqt
better starts deploying the Wayland platform plugin whenever libQtXGui.so is being deployed.
Metadata
Metadata
Assignees
Labels
Projects
Milestone
Relationships
Development
Select code repository
Activity
TheAssassin commentedon Nov 20, 2017
Due to XWayland being installed on distributions, this shouldn't be a problem in the near future. But yes, it'd be nice if the applications would natively run on Wayland (if available).
We have to investigate whether deploying the Wayland platform plugin will mean that Qt switches to Wayland if available, and falls back to X11 otherwise.
probonopd commentedon Nov 20, 2017
Thanks @TheAssassin I was assuming that XWayland will not go away anytime soon. At least not in the LTE and Enterprise distributions that we are trying to (also) target with AppImages.
TheAssassin commentedon Nov 20, 2017
XWayland will probably stay for years. The point is, why bother using XWayland, when you can use Wayland directly.
DiabeticCrab commentedon Feb 20, 2023
@probonopd Could you please stop blocking this issue from being resolved and finally merge #540?
It's silly to prohibit a highly demanded feature from being implemented due to ideological reasons and this is hurts AppImage as a whole!
probonopd commentedon Feb 20, 2023
It has been claimed that Wayland can run X11 applications using XWayland. So it should be able to run "normal" applications just fine?
Elsie19 commentedon Feb 21, 2023
So should we all just run every application we need that has a windows exe under wine or should we all use the native version?
probonopd commentedon Nov 5, 2023
Wayland is still so broken that you can't even set window icons ("Using
QT_QPA_PLATFORM=xcb
works, though")https://bugreports.qt.io/browse/QTBUG-101427
If you want to set icons on windows, unlike all other windowing systems apparently Wayland forces one to install
.desktop
files into the system and use (reverse-DNS notation) application IDs - concepts AppImage is not using.Blocked by (among others):
DiabeticCrab commentedon Nov 10, 2023
So your plan is continuing to stall, because some non-critical inconvenience hasn't been sorted out yet? I agree that it needs fixing, but it certainly isn't a blocker. Are you bananas?
CodeMystic21 commentedon Nov 10, 2023
just because they kind of work doesn't mean a want to run my software in legacy x11 mode.
CodeMystic21 commentedon Nov 10, 2023
Oh what a great idea with wine. Even better idea: why not then got back to the for sure best operating system and run it NATIVE on windows ..... 🤣
benma commentedon Jan 9, 2025
Workaround, tested on Qt6.2.4:
-extra-plugins=platforms/libqwayland-generic.so,platforms/libqwayland-egl.so,wayland-graphics-integration-client,wayland-decoration-client,wayland-shell-integration
The list of related plugins was found by:
find $(qmake -query QT_INSTALL_PLUGINS) | grep wayland
Without this, our app was a bit blurry on a user's computer running wayland - seems to be a common problem with running with the xcb platform on wayland. We do see the window icon in the top left is missing (like @probonopd's remarked above), but that is a small cost to pay for an app that otherwise works and is not rendered blurry.
You'll also need these two packages installed on the build machine where you run linuxdeployqt:
edit: the above works also on Qt 6.8.2, but you will probably also need
-exclude-libs=libwayland-client.so.0
, see #631saturneric commentedon Apr 22, 2025
@benma I suppose you can just simply add
-extra-plugins=platforms
.probonopd commentedon Apr 22, 2025
Wayland is so broken that not even a
move()
works on aQMainWindow
.