6 ms·

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 t

by vially 5y ago

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 https://gitlab.gnome.org/GNOME/mutter/-/issues/217 [2] - https://github.com/electron/electron/issues/27522 https://github.com/electron/electron/issues/27522

akvadrako 5y ago
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-716152639 https://github.com/electron/electron/pull/26022#issuecomment...
- zxzax 5y ago
  You are responding to the same person who wrote that comment, with their own comment :)
  - johnhenry 5y ago
    :)
zxzax 5y ago
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-win-lg.png https://code.visualstudio.com/assets/home/home-screenshot-wi... [1] https://a.slack-edge.com/a084c/marketing/img/downloads/screenshots/windows/windows-hero-desktop.png https://a.slack-edge.com/a084c/marketing/img/downloads/scree... [2] https://pureinfotech.com/wp-content/uploads/2019/12/microsoft-teams-linux.jpg 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.jpg https://www.chip.de/ii/1/1/4/4/7/3/5/4/0/ea621fe64b8418e9.jp...
- vially 5y ago
  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.
  - zxzax 5y ago
    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.
    - vially 5y ago
      > 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_356962 https://gitlab.gnome.org/GNOME/mutter/-/issues/217#note_3569...

by vially 5y ago

akvadrako 5y ago

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-716152639 https://github.com/electron/electron/pull/26022#issuecomment...

zxzax 5y ago
You are responding to the same person who wrote that comment, with their own comment :)
- johnhenry 5y ago
  :)

zxzax 5y ago

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-win-lg.png https://code.visualstudio.com/assets/home/home-screenshot-wi... [1] https://a.slack-edge.com/a084c/marketing/img/downloads/screenshots/windows/windows-hero-desktop.png https://a.slack-edge.com/a084c/marketing/img/downloads/scree... [2] https://pureinfotech.com/wp-content/uploads/2019/12/microsoft-teams-linux.jpg 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.jpg https://www.chip.de/ii/1/1/4/4/7/3/5/4/0/ea621fe64b8418e9.jp...

vially 5y ago
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.
- zxzax 5y ago
  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.
  - vially 5y ago
    > 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_356962 https://gitlab.gnome.org/GNOME/mutter/-/issues/217#note_3569...