-
Notifications
You must be signed in to change notification settings - Fork 907
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
base: master
Are you sure you want to change the base?
Conversation
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. |
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 |
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.
@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. |
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.
Ok, I've changed the launcher logic so that by default the client will continue using xwayland backend, unless |
ping? 😄 |
|
@edisionnano what you mean, is that if you launch the current snap with such arg? A part you may need more ( |
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.