Hacker News Reader

Comment by vially | Hacker News Reader

I've been using it for a couple of months now (by patching the applications which haven't upgraded to Electron 12 yet) and it's been working great for me.

Is there anything in particular that is broken and/or missing from Electron's Wayland implementation? Or are you referring to GNOME's refusal to implement server-side decorations [1][2] as a limitation of Electron?

[1] - https://gitlab.gnome.org/GNOME/mutter/-/issues/217 [2] - https://github.com/electron/electron/issues/27522

View on HN

I don't think GNOME adding SSD would really help, considering a lot of Electron apps tend to use CSD to integrate with the target platform [0] [1] [2] [3]. Likely those apps should be fixed to correctly use CSD when applicable on all platforms, including GNOME.

[0] https://code.visualstudio.com/assets/home/home-screenshot-wi... [1] https://a.slack-edge.com/a084c/marketing/img/downloads/scree... [2] https://pureinfotech.com/wp-content/uploads/2019/12/microsof... [3] https://www.chip.de/ii/1/1/4/4/7/3/5/4/0/ea621fe64b8418e9.jp...

My impression is that there will always be apps that don't care enough about decorations and would just prefer to use the operating system defaults and SSD provided a reasonable way to do that. But then there are also applications that do care enough about it, in which case CSD is way to go.

Usually implementing CSD properly for each platform requires a bit more work than just relying on the toolkit's default or on SSD. This shouldn't be a problem for applications that have the resources to do this properly, as in your examples. But I'm a bit afraid that, given Linux desktop's market share, smaller app developers might not have the resources to do this right and then Linux will start inheriting the look and feel from Windows and macOS. Maybe this won't be a problem in practice, but if this starts happening, then the experience for Linux desktop users will be worse than just using SSD.

In any case, we'll have to wait and see how it all plays out. I think both SSD and CSD have their use-cases and I still wish GNOME's would reconsider their position on this.

For apps that don't care about decorations, the toolkit is supposed to handle it. Inside Electron would be the safest place to implement a fallback for applications that don't care about decorations. That way you can be sure it will work on any window manager that doesn't provide decorations, not just GNOME... I don't want to retread more of the discussion that was in the github issue, but one way to do it is to have Electron hook into GTK and draw the GTK decorations, like Firefox does.

GNOME is an open source project, asking them to reconsider a position doesn't make sense -- the default response to every feature request is "no" unless someone volunteers to implement it. And honestly I see very little chance that the current GNOME volunteers are going to implement server side decorations in Wayland unless someone outside the project steps up to do the work. Maybe Canonical would pay for it? It's a major change for something that no GTK/GNOME apps would even use, and it wouldn't really benefit those small applications... they would still have to draw their own decorations to handle any other window manager that doesn't implement decorations, such as Weston.

> GNOME is an open source project, asking them to reconsider a position doesn't make sense -- the default response to every feature request is "no" unless someone volunteers to implement it

I don't think GNOME would accept a pull-request adding SSD regardless of where it came from (I'd love to be proven wrong though). In fact, someone asked this exact question [0] and it got no reply. But after reading the whole thread a while ago my takeaway was that such a pull-request would not be accepted.

> [...] it will work on any window manager that doesn't provide decorations, not just GNOME.

GNOME is the only real desktop compositor that doesn't support SSD. The main reason no one is complaining about Weston not supporting server-side decorations is because there aren't many (any?) people running Weston on the desktop. Also, there's no technical reason why SSD couldn't be added to Weston too.

Again, as I've mentioned before I think both SSD and CSD have their use-cases. GNOME thinks otherwise and that's okay. But it doesn't seem to be (only) due to lack of resources.

[0] - https://gitlab.gnome.org/GNOME/mutter/-/issues/217#note_3569...

The pull request probably wouldn't be accepted because it's a major change and no other Mutter contributors are interested in reviewing such a patch or dealing with the (far-reaching) effects of it. GNOME is just the nonprofit open source project and it doesn't really allocate resources or have resources to spare -- it's got to be a volunteer who works on this who has enough resources to do it in a way that doesn't mess it up for everyone else, maybe that's Canonical who can do it, I don't know. There is also the option of implementing it first in one of the forks (Elementary, Budgie, etc), testing it out for a while, and then submitting it later after it's known that it works and doesn't break everything. Getting upstream to accept a 10,000 line patch is not easy under any circumstances.

There are other window managers that don't support server side decorations, I don't know why people always single out GNOME. Weston is important too, it's not often used directly but it's used as a base for other implementations -- if your app is busted and has no decorations on the reference implementation it can hardly be called a working Wayland app. Server side decorations do have a use case but they're not equivalent to client side decorations. I used to think they were until I tried to implement them in a window manager, now I see server side decorations as mostly a broken concept unless it's in very specific circumstances. The toolkits and apps have to implement client side decorations if they want to ensure the correct behavior everywhere, it's unavoidable.

It's by their own admission, this is "very experimental" in Electron 12 and hence not enabled by default.

https://github.com/electron/electron/pull/26022#issuecomment...

You are responding to the same person who wrote that comment, with their own comment :)

Reply on news.ycombinator.com