-
-
Notifications
You must be signed in to change notification settings - Fork 566
Wayland
As of Fedora 27, Fedora ships with Wayland as the default display server. According to users' reports, there are additional manual steps required to make some applications run correctly on Wayland. It appears that this has nothing to do with AppImage specifically. Thanks @sudo-give-me-coffee for writing down the steps to do in order to make applications, e.g., Mudlet, work on Fedora:
xdg-user-dirs-update
sudo su
cd ~
xdg-user-dirs-update
If you are getting Could not connect to display :0 then you need to install XWayland.
According to https://blog.martin-graesslin.com/blog/2018/03/unsetting-qt_qpa_platform-environment-variable-by-default/,
Since the introduction of the Plasma/Wayland session we set the QT_QPA_PLATFORM variable to wayland by default. After a long and hard discussion we decided to no longer do this with Plasma 5.13. This was a hard decision and unliked by everyone involved. (...) But how can it happen that the qpa platform plugin is missing although Plasma itself happily uses it? The problem is that application installed outside of the system bundle their own Qt and Qt does not (yet) include QtWayland QPA platform plugin. This affects proprietary applications, FLOSS applications bundled as appimages, FLOSS applications bundled as flatpaks and not distributed by KDE and even the Qt installer itself. In my opinion this is a showstopper for running a Wayland session.
The desktop environment should not assume that every Qt on the system already has the QtWayland QPA platform plugin. It seems that we should include the QtWayland QPA platform plugin going forward; but in the meantime distributions should not set the QT_QPA_PLATFORM variable to wayland by default. if yours does, unset it.
References: