Skip to content
This repository has been archived by the owner on Dec 14, 2021. It is now read-only.

Wayland support in AppImage build? #1017

Open
bam80 opened this issue May 18, 2020 · 7 comments
Open

Wayland support in AppImage build? #1017

bam80 opened this issue May 18, 2020 · 7 comments

Comments

@bam80
Copy link
Contributor

bam80 commented May 18, 2020

Hello, thank you for awesome app!
Currently it can't run on Wayland natively, corresponding qt plugin seems missed:

$ QT_QPA_PLATFORM=wayland Applications/Sourcetrail_2020_1_117_Linux_64bit_838fbdbb027567876d3da8cf74c6d512.AppImage 
QCoreApplication::applicationDirPath: Please instantiate the QApplication object first
ERROR: Please run Sourcetrail via the Sourcetrail.sh script!
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
qt.qpa.plugin: Could not find the Qt platform plugin "wayland" in ""
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: xcb.

Aborted (core dumped)

#945 #279

@GbGp
Copy link

GbGp commented Aug 18, 2020

I don't have any problem running this software on wayland compiling from the sources, but the packages from the release page doesn't work for me as well. I think they were probably built on a system without the QtWayland module installed so they don't ship the required platform plugins:
https://wiki.qt.io/QtWayland

@bam80 bam80 changed the title Wayland support? Wayland support in AppImage build? Aug 18, 2020
@bam80
Copy link
Contributor Author

bam80 commented Aug 18, 2020

linuxdeployqt AppDir/usr/share/applications/sourcetrail.desktop -qmake=$Qt5_DIR/bin/qmake -ignore-glob=*python* -appimage

@egraether could you confirm the docker build container contains QtWayland plugin? If so, maybe we should add it explicitly:

Adding extra Qt plugins

If you want aditional plugins which the tool doesn't deploy, for a variety of reasons, you can use the -extra-plugins argument and include a list of plugins separated by a comma.

https://github.com/probonopd/linuxdeployqt#adding-extra-qt-plugins

@bam80
Copy link
Contributor Author

bam80 commented Aug 18, 2020

#279 (comment)

mkdir -p appdir/usr/plugins/platformplugins/
cp /usr/lib/x86_64 /usr/plugins/platformplugins/qtwayland.so  appdir/usr/plugins/platformplugins/

# If you also want to deploy its dependencies, do something like this - but I don't think you want to bring Wayland libs to non-Wayland systems, so probably it's best NOT to do this
linuxdeployqt AppDir/usr/share/applications/sourcetrail.desktop -qmake=$Qt5_DIR/bin/qmake -ignore-glob=*python* -appimage -executable=appdir/usr/plugins/platformplugins/qtwayland.so

@probonopd Thanks. Wouldn't just -extra-plugins argument mentioned above do the job?

@probonopd
Copy link

can't run on Wayland natively

Doesn't Wayland come with a compatibility layer to be able to run the vast amount of existing Xorg applications?

@bam80
Copy link
Contributor Author

bam80 commented Aug 25, 2020

Yes it can be run as XWayland client, but that might have some drawbacks, so IMO it's worth just add proper Qt plugin, to have ability run app without any emulation layers.

@probonopd
Copy link

probonopd commented Aug 25, 2020

Then just copying the plugin to appdir/usr/plugins/platformplugins/qtwayland.so manually should do, as running things like -executable=appdir/usr/plugins/platformplugins/qtwayland.so or -extra-plugins would have the undesirable effect of also pulling in Wayland dependency libraries, which would not add any benefit on non-Wayland systems (and Wayland systems have them on the system anyway).

(For me personally, Wayland is and has been broken since it breaks compatibility with the existing screen recording and screen sharing apps. There seems to be no willingness from the Wayland developers to respect the existing software base out there by respecting the existing Xorg APIs. So I try to avoid using Wayland.)

@Alexmitter
Copy link

@probonopd Sorry to interject but that is just wrong. The Xorg "API" applications use to read the screen is simply them reading Xorgs buffer. This isnt a API, this is a dirty hack and there is no excuse for it. Are you seriously asking the wayland people write something that emulates Xorgs buffer so applications using a dirty hack to record the screen continue to work?
There is a proper API now, something that asks the user before a application can record anything, and all the usual applications already support it.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants