Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

snap: Run as native wayland client if possible #2480

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

3v1n0
Copy link
Contributor

@3v1n0 3v1n0 commented Nov 24, 2023

The new electron versions support wayland natively, this implies that mailspring can use the native rendering when in a wayland desktop environment, bringing various benefits including a better rendering in high DPI displays.

To enable this electron still requires some flags, so add a wrapper launcher that is used to enable them unless wayland isn't explicitly disabled.

@jpeeler
Copy link

jpeeler commented Dec 6, 2023

FWIW, I wasn't even able to open Mailspring using the flatpak on Hyprland without XWayland until I used the flags (--enable-features=WaylandWindowDecorations --ozone-platform=wayland --use-gl=desktop) here.

@bengotow
Copy link
Collaborator

Hey @3v1n0 thanks for all your contributions around this -- do you know what if any additional testing should be done here? I've found this Snap stuff to be fairly finicky and my only hesitation around this is that we might break one of the two paths taken by this new wrapper (wayland/non-wayland) in the future without noticing.

@3v1n0
Copy link
Contributor Author

3v1n0 commented Dec 11, 2023

Hey @3v1n0 thanks for all your contributions around this -- do you know what if any additional testing should be done here? I've found this Snap stuff to be fairly finicky and my only hesitation around this is that we might break one of the two paths taken by this new wrapper (wayland/non-wayland) in the future without noticing.

So, the testing to do is try to run this in both wayland and X11, but in my tests there are no issues.

I've been testing this mostly on 22.04 and 23.10, but I may also give 20.04 a shot if you want.

The wrapper is needed to check what backend to use, since wayland is not default in electron yet. But I had no issues so far.

Also, together with this we may need to add a documentation line mentioning that snap set mailspring wayland-native=false can be used to turn this off and just use the very same behavior of other versions.

The new electron versions support wayland natively, this implies
that mailspring can use the native rendering when in a wayland
desktop environment, bringing various benefits including a better
rendering in high DPI displays.

To enable this electron still requires some flags, so add a wrapper
launcher that is used to enable them unless wayland isn't explicitly
disabled.
@3v1n0
Copy link
Contributor Author

3v1n0 commented Jan 10, 2024

@bengotow any news here?

If you prefer to be conservative, we could make the wayland option to be manually set. This could be also controlled by the UI making the wrap read a figuration file, but IMHO it's an option that can stay at host level.

@BohdanTkachenko
Copy link

Thanks for working on this!

IMHO a conservative way is still far better than workarounds we have to use. I wasn't even able to pass these flags to a snap version at all (permission issue I believe), so I had to install a deb package.

Once a flag is available to use we all could give it a try and provide some feedback if this can be safely enabled by default.

Make possible for users to enable the native wayland client by using
  snap set mailspring wayland-native=true

By default mailspring will use xwayland, but the support can be toggled
by users with the said command.
@3v1n0
Copy link
Contributor Author

3v1n0 commented Jan 12, 2024

Ok, I've changed the launcher logic so that by default the client will continue using xwayland backend, unless sudo snap set mailspring wayland-native=true is used.

@3v1n0
Copy link
Contributor Author

3v1n0 commented Apr 18, 2024

ping? 😄

@edisionnano
Copy link

Requested GL implementation (gl=desktop-gl,angle=none) not found in allowed implementations: [(gl=egl-gles2,angle=none),(gl=egl-angle,angle=swiftshader)] when trying --use-gl=desktop outside snap

@3v1n0
Copy link
Contributor Author

3v1n0 commented May 21, 2024

@edisionnano what you mean, is that if you launch the current snap with such arg?

A part you may need more (--enable-features=WaylandWindowDecorations --ozone-platform=wayland --use-gl=desktop), but also the current snap launcher defines DISABLE_WAYLAND that implies changes in the desktop launcher that won't make it work

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

Successfully merging this pull request may close these issues.

5 participants