Proper wayland support

[ghost]

Have you checked for existing feature requests?

• Completed

Summary

Support wayland using the electron wayland flags.

What benefits does this feature provide?

Future proofs the software

Any alternatives?

No

Other examples:

No response

[confused-Techie]

I believe what this issue is asking is for us to add the following flags when electron is starting pulsar --enable-features=UseOzonePlatform --ozone-platform=wayland

Which I was able to find here, since the official Electron Docs don't seem to make any mention of this.

Additionally I wouldn't say this future proofs the software. Really just provides better support for users on Linux Wayland. Which I wonder if there's a way for us to autodetect that when starting up on Linux, or if using these flags when not on a Wayland system would cause any issues.

[meadowsys]

The easiest, most basic implementation would just expose an option to start up with these flags, perhaps this could be exposed as a setting for linux users? I think unless someone knows how to do this detection automatically and its not much effort, its probably quickest to get at least manual support in somehow

[joshcangit]

Looked up some Stack Overflow.
https://stackoverflow.com/q/45536141

One of the answers says it's better to check for Wayland first then X.

[Spiker985]

XDG_SESSION_TYPE will contain either x11 or wayland

Ideally, this can be added to pulsar.sh

[ghost]

Hello, I forgot to mention in the original issue that the wayland flags currently are not working for pulsar. That is why I made this issue.

[Spiker985]

I'm assuming this is because when pulsar starts up, I believe in the src/main-process/atom-application.js file, it sets the flags for the window, and there's no CLI integration to forward those along

[meadowsys]

yeah thats what I assumed too ><

[herzenschein]

I can confirm this doesn't work, at least with the flatpak. Neither the flags --enable-features=UseOzonePlatform --ozone-platform=wayland (which makes sense, as the flatpak simply runs pulsar.sh and sets flags elsewhere), or the following config files: ~/.config/electron-flags.conf, ~/.config/electron12-flags.conf, ~/.config/chrome-flags.conf, or their equivalents inside ~/.var/app/dev.pulsar_edit.Pulsar/config/.

Also, because the Pulsar flatpak seems to be using Electron 12, it won't have the latest improvements on Wayland, most notably the XDG FileChooser Portal added in Electron 14 or the automatic detection from Electron 20.

The automatic detection thing answers the above doubt:

if using these flags when not on a Wayland system would cause any issues.

--ozone-platform-hint=auto defaults to Wayland if available, X11 as a fallback.

Although it would already be plenty useful if users could manually set it themselves.

[Daeraxa]

We do not currently support the flatpak, that distribution is not provided by us. We do want to support it eventually but things like the above issues relating to electron versions and proper support of the XDG base spec need to be considered so we can actually make a reliable flatpak distribution that we can support without having to account for weird edge cases.

[ghost]

Any news on this?

[confused-Techie]

@jakedevs nothing yet, but we wouldn't be opposed to a PR if you have a chance. But otherwise hopefully someone can get to it

[mauricioszabo]

@jakedevs I feel that this will only be addressed when we upgrade Electron to a newer version - which is not an easy thing to do, honestly.

That being said - we do have a working version for Pulsar on Electron 24, that may work for you: https://cirrus-ci.com/github/pulsar-edit/pulsar/feature%2Flatest-electron. I am actually using it for my day-to-day work, but most packages that depend on native modules don't work.

But if you want, feel free to try. The changes on that build are present in #484. Please notice that the builds are not passing but the binary is generated, so you can try it if you want :)

[4ntsu]

Hi Pulsar devs.

First of all, thank you very much for your efforts in this project.

I understand that these "are we there yet?" or "me too" kind of posts are not helpful, and you'd rather get a PR with a fix, but since I'm not in a position to provide that, I'd like to at least mention a few things that may add perspective to this issue.

In these five years since this issue was originally opened, Wayland has evolved a lot, and is now the default on several distros. It offers better performance and security compared to X11, and most Electron-based applications support it by now, either natively or via user-defined flags.
While I agree that for most use-cases using X11 mode via Xwayland is good enough, things are very different when fractional scaling comes into play on high DPI displays (which are becoming increasingly common). Even at just 125% scaling, the entire interface and text input area become noticeably blurry, and quite unpleasant to use.

I believe proper Wayland support would be an important improvement for Pulsar when you can find the time and resources to implement it.

[mauricioszabo]

Hi, @4ntsu - yes, we're aware of these. For now, we do have a version that runs on Wayland. It still have a lot of issues that need to be solved, but it is completely usable: #484

If you want to live on the bleeding edge (like I do - seriously, I use this "newest Electron" version, and have been using it for about 3 months now) you can grab a binary directly from the CI: https://cirrus-ci.com/github/pulsar-edit/pulsar/feature%2Flatest-electron (don't mind the "Failed" badge, that's basically because Windows is not passing, as always, but fortunately Linux and Mac (both archs) are)

The power of community packages is what makes Pulsar so powerful, and unfortunately, some widely used packages like Hydrogen and basically all terminals are broken now (there's a workaround for x-terminal-reloaded by the way), but even then, we're discussing a way to make this version available from our downloads session, maybe under an "unstable" flag.

[4ntsu]

Thank you @mauricioszabo.
I have tried the latest build from that branch, but it appears to be lacking the Git/Github integration, which I use quite a lot. Trying to install the Github extension from the Settings>Install page results in a long error, on both Ubuntu and Arch, which I suppose is to be expected on an unstable branch build. I'm putting the log below, in case it is of any use.

Installing “github@0.36.10” failed.Hide output…

> superstring@2.4.4 install /tmp/apm-install-dir-2023614-5756-tcooic.1e2z/node_modules/github/node_modules/superstring
> node-gyp rebuild


npm WARN deprecated core-js@2.6.12: core-js@<3.23.3 is no longer maintained and not recommended for usage due to the number of issues. Because of the V8 engine whims, feature detection in old core-js versions could cause a slowdown up to 100x even if nothing is polyfilled. Some versions have web compatibility issues. Please, upgrade your dependencies to the actual version of core-js.
(node:5781) [DEP0150] DeprecationWarning: Setting process.config is deprecated. In the future the property will be read-only.
(Use `node --trace-deprecation ...` to show where the warning was created)
gyp ERR! build error 
gyp ERR! stack Error: not found: make
gyp ERR! stack     at getNotFoundError (/opt/Pulsar/resources/app/ppm/node_modules/npm/node_modules/which/which.js:13:12)
gyp ERR! stack     at F (/opt/Pulsar/resources/app/ppm/node_modules/npm/node_modules/which/which.js:68:19)
gyp ERR! stack     at E (/opt/Pulsar/resources/app/ppm/node_modules/npm/node_modules/which/which.js:80:29)
gyp ERR! stack     at /opt/Pulsar/resources/app/ppm/node_modules/npm/node_modules/which/which.js:89:16
gyp ERR! stack     at /opt/Pulsar/resources/app/ppm/node_modules/npm/node_modules/isexe/index.js:42:5
gyp ERR! stack     at /opt/Pulsar/resources/app/ppm/node_modules/npm/node_modules/isexe/mode.js:8:5
gyp ERR! stack     at FSReqCallback.oncomplete (node:fs:194:21)
gyp ERR! System Linux 5.19.0-46-generic
gyp ERR! command "/opt/Pulsar/resources/app/ppm/bin/node" "/opt/Pulsar/resources/app/ppm/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /tmp/apm-install-dir-2023614-5756-tcooic.1e2z/node_modules/github/node_modules/superstring
gyp ERR! node -v v16.0.0
gyp ERR! node-gyp -v v5.1.1
gyp ERR! not ok 
npm WARN enoent ENOENT: no such file or directory, open '/tmp/apm-install-dir-2023614-5756-tcooic.1e2z/package.json'
npm WARN @atom/babel-plugin-chai-assert-async@1.0.0 requires a peer of test-until@1.x but none is installed. You must install peer dependencies yourself.
npm WARN apm-install-dir-2023614-5756-tcooic.1e2z No description
npm WARN apm-install-dir-2023614-5756-tcooic.1e2z No repository field.
npm WARN apm-install-dir-2023614-5756-tcooic.1e2z No README data
npm WARN apm-install-dir-2023614-5756-tcooic.1e2z No license field.

npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! superstring@2.4.4 install: `node-gyp rebuild`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the superstring@2.4.4 install script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/antsu/.pulsar/.apm/_logs/2023-07-14T14_50_01_819Z-debug.log

[Spiker985]

In order to get that unstable branch to be on the version of electron it's on, we did have to unfortunately not include the github integration as it is one of the reasons we can't make the jump outright

[RayJW]

I just want to add to this discussion that the problem with auto-detection can now be fixed with recent Electron releases by using --ozone-platform-hint=auto. That way the Wayland backend is only used for users on Wayland and the same for X11. Also, they introduced support for the env variable ELECTRON_OZONE_PLATFORM_HINT in the latest alpha in case you don't want to enable the Wayland backend by default, that way you can at least still respect the users' preference.