-
Notifications
You must be signed in to change notification settings - Fork 15.3k
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
[Feature Request] Support CSD in Wayland #27522
Comments
Leaving aside the meat of this request, I did want to point out one misconception:
This is not true. There exists a protocol ( See: |
Thanks for the suggestion! I know the Electron project would be very happy to have better Wayland support but I don't think there is anyone on the project actively working on this right now. If anyone in the community wants to contribute work to this, I for one would be very happy about that. |
An unstable optional/extension protocol which even states that a valid |
I didn't know about xdg-decoration, I edited the description to account for this. Thank you. |
Yes, agreed, I was only pointing out against the (probably unintentional) absolutist "there are no SSDs [in Wayland]" (emphasis mine). There is an extension for negotiating SSDs that KDE and wlroots implement. It's not supported by GNOME. Electron doesn't strictly use core Wayland protocols. Leaving aside personal opinions on the matter, this is the current state of decorations on Wayland :)
Note that KDE's Wayland support isn't based on wlroots :) |
I remember having read the post by Tobias @Xyene linked at the time, I mean https://blogs.gnome.org/tbernard/2018/01/26/csd-initiative/. Rereading it now I realize Electron was mentioned as a potentially easy case:
|
Note Tobias made that comment from the perspective of app developers using it, not electron providing it |
Yes, that's true, but I assume that the fact that apps are doing this in MacOS, combining their own widgets with platform provided ones in a coherent way, means that the abstractions are right there in Electron and we need to implement them, not define them. I ignore everything about Electron, TBH, so I'm going to take a look later. |
Just want to add here that |
@christianrauch I can't see any much activities there it looks like a prototype. Also, it does not support Enignlement. |
What activity would you expect?
What is "Enignlement"? Is it an application? If the decorations don't work as expected with your application then please open an issue so we can review if this is an issue with |
Possibly a reference to the Enlightenment desktop/compositor, which does support client-side decorations in wayland: https://www.enlightenment.org/about-wayland |
I'm looking for clarification and also take this with a grain of salt since it's been a while since I last worked on anything electron but: AFAIR the buttons used in mac and windows were a bit more bespoke/custom than they looked because since windows & mac both are one singe platforms we knew where the buttons had to be and how they looked so apps just implemented buttons looking like that (and I guess on mac you can request the system to draw the buttons for you). But for true CSD support on Linux it's not that simple because on Linux you can configure where you want the buttons, which buttons do you want and how the buttons look. So for true CSD the apps need to implement a way to handle button arrangement so that it follows the system style (left/right, which buttons) and either devise a way to make sure current button style looks good/usable with their app theme or just use custom assets for the icon. Which leads me to my conclusion/questions/clarification:
|
@rohmishra You are correct. In reality, Server Side Decorations are the simplest way to implement thing for developers: applications will be drawn with buttons (and everything else) in whichever way the user configured it in whatever desktop they may be using. It's what works almost everywhere, and works best. Gnome is the notable exception, since it requires applications to use CSD. This forces applications to have explicit support for Gnome (my understand is that it's to kinda force applications to have dedicated Gnome-support, further pulling them into the Gnome/Gtk ecosystem). I don't think there's any way to have customised decorations with SSDs though; it's generally an all-or-nothing kind of thing. |
Except Wayland (and yes Wayland not GNOME), so a no-go |
What are you talking about? Wayland itself support SSDs just fine. It's merely GNOME that has decided not to support it. This is why applications require special support for GNOME, other compositors implement SSDs. |
No it doesn't, the Wayland spec has no concept of decorations |
To avoid going in circles about Wayland support for SSDs, please see the second comment in this thread: #27522 (comment) |
It seems that wayland itself doesnt require SSD. While there is a protocol to implement SSD (just like there is a protocol to implement screen capture, pipewire) but it isnt part of wayland itself. So to be compliant with wayland electron HAS to draw its own decorations because wayland allows compositors to not care about decoration it they dont want to. In addition we also need a way for electron apps to be able to read layout so that if apps want to implement their own button style (like in ss below, true CSD), they know where to place them. I say that because it looks like gnome team themselves seem to be ok with buttons using their own styling and even speaking personally i dont care about how the buttons look but having them at wrong place & configuration (on right as opposed to left where all other buttons are on my system) is what infuriates me more. Gtk4 AFAIK does allow you to just get the window buttons like macOS which can be used instead when electron eventually updates to using gtk4. |
That's not correct. Pipewire (and xdg-desktop-portal for that matter) is not a wayland protocol indeed. But xdg-decoration is a wayland protocol. |
Oh, I was mistaken about it. Sorry About that.
It does seem that the protocol implies that decorations might not be implemented by compositor and apps should have some fallback regardless. |
I'd suggest that we don't need to get button placement and sequence perfect on the first try We mostly just need to detect when SSD is not provided/negotiated, and draw a CSD with an exit button, at a minimum Offering some sort of customisation or WM-detection that puts CSD buttons in the correct WM-specific conventional sequence could come later |
@jokeyrhyme Since we already depend on gtk which does provide GtkHeaderBar, is it not possible to just ask toolkit (gtk) to draw it for us like you can with regular gtk apps? edit: came aross #11907 (comment) which kinda answers the question. Although electron depends on gtk, the windows that is presented is not actually a GtkWindow. |
wonders if people actually read prior comments It would seem to me making use of GtkHeaderBar/GtkWindowControls would make sense for electron (the latter requiring gtk4, though you could implement it for gtk3), the alternative being libdeco(ration) Whilst electron could try to parse |
The core spec cannot open a window (ignoring the deprecated and largely unsupported wl_shell), and weston supports many non-core, non-stable protocols. wayland-protocols is a collection of additional shared protocols. While the "stable" xdg-shell protocol will be used to create windows, you will also be using protocols from the "unstable" set—at the very least linux-dmabuf for GPU buffers. You will likely also use the unstable primary-selection protocol for X11-style clipboard, text-input for IME support, tablet for drawing tablet tool integration, and so forth. All the protocols in there are optional and may or may not be provided by a given Wayland compositor, including xdg-shell and linux-dmabuf. Compositor developers decide which they provide, application developers decide which they use and which they require. GNOME not wishing to support xdg-decoration, while slightly frustrating, is not particularly weird—other compositors exclude other protocols after all. And yes, compositors not implementing xdg-shell are more common that you would think. Chromium and Gtk uses many unstable protocols. Gtk even supports server-side decorations—even though Mutter does not support it—through the pre-cursor to xdg-decoration, the "super-unstable" org-kde-kwin-server-decoration-manager. With all that out of the way, all that remains is the question as to whether support for server-side decoration is wanted. If wanted, xdg-decoration is the preferred way to request a decoration mode. Links:
|
Looks like this is a duplicate of #27016 |
Closes electron#27522. Signed-off-by: Ryan Gonzalez <rymg19@gmail.com>
Closes electron#27522. Signed-off-by: Ryan Gonzalez <ryan.gonzalez@collabora.com>
Closes electron#27522. Signed-off-by: Ryan Gonzalez <ryan.gonzalez@collabora.com>
Preflight Checklist
Problem Description
In Wayland clients usually render their own decorations, they don't get SSD anymore (although there seems to be a protocol for SSD negotiation that Plasma and some compositors based on wlroots implement). The Wayland build is not very useful until Electron app windows get a proper headerbar. The headerbar can be a stock headerbar similar to old-school SSD or can be customized by the app (for example, by setting its color/theme in accordance with the app contents).
Proposed Solution
Use GTK CSD support, which is also well-integrated in Qt-based environments (mainly Plasma):
https://developer.gnome.org/gtk3/stable/GtkHeaderBar.html:
https://developer.gnome.org/gtk3/stable/GtkSettings.html#GtkSettings--gtk-decoration-layout:
Alternatives Considered
It doesn't seem to exist much more alternatives. Maybe Qt has a native headerbar implementation, but it won't properly work inside a GTK-based environment like GNOME, while it works the other way around. See https://pointieststick.com/2019/11/30/this-week-in-kde-gtk-csd-support-and-more
Maybe xdg-decoration as suggested in some comments below. But I ignore everything about it and SSD doesn't seem to me the best alternative for Electron apps that tend to be more app-centric than platform-centric by its very nature and so, at least in major platforms, usually customize headerbars.
Additional Information
More details in discussion starting from #10915 (comment)
The text was updated successfully, but these errors were encountered: