[Feature Request] Support CSD in Wayland

[memeplex]

Preflight Checklist

• I have read the Contributing Guidelines for this project.
• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a feature request that matches the one I want to file, without success.

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:

void gtk_header_bar_set_show_close_button (GtkHeaderBar *bar, gboolean setting);

Sets whether this header bar shows the standard window decorations, including close, maximize, and minimize.

https://developer.gnome.org/gtk3/stable/GtkSettings.html#GtkSettings--gtk-decoration-layout:

“gtk-decoration-layout”    char *

This setting determines which buttons should be put in the titlebar of client-side decorated windows, and whether they should be placed at the left of right.

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)

[Xyene]

Leaving aside the meat of this request, I did want to point out one misconception:

In Wayland all clients have to render their own decorations, there are no SSD anymore.

This is not true.

There exists a protocol (xdg-decoration) that at least KDE and Sway/wlroots implement, allowing negotiation of SSDs. What is true is that GNOME have made it very clear they will not implement this protocol, such that applications wishing to have decorations on GNOME must implement CSDs.

See:

• https://gitlab.gnome.org/GNOME/mutter/-/issues/217
• https://blog.martin-graesslin.com/blog/2018/01/server-side-decorations-and-wayland/
• https://blogs.gnome.org/tbernard/2018/01/26/csd-initiative/

[ckerr]

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.

[ZanderBrown]

There exists a protocol

An unstable optional/extension protocol which even states that a valid xdg-decoration implementation doesn't actually have to support SSD, so whilst it may be something electron is interested in it is not the solution you are looking for as even when xdg-decoration is present (and at least on GNOME it isn't) it may not do anything

[memeplex]

In Wayland all clients have to render their own decorations, there are no SSD anymore.

This is not true.

I didn't know about xdg-decoration, I edited the description to account for this. Thank you.

[Xyene]

.. so whilst it may be something electron is interested in it is not the solution you are looking for ...

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 :)

I edited the description to account for this.

Note that KDE's Wayland support isn't based on wlroots :)

[memeplex]

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:

Many Electron apps might be low-hanging fruit, because they already use CSD on macOS. This means it should be possible to make this happen on GNU/Linux as well without major changes to the app. However, some underlying work in Electron to expose the necessary settings to apps might be required first.

[ZanderBrown]

Note Tobias made that comment from the perspective of app developers using it, not electron providing it

[memeplex]

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.

[christianrauch]

Just want to add here that libdecor could be used specifically to implement client-side decorations under Wayland.

[stalkerg]

@christianrauch I can't see any much activities there it looks like a prototype. Also, it does not support Enignlement.

[christianrauch]

I can't see any much activities there it looks like a prototype.

What activity would you expect? libdecor is a library that only implements window decorations, nothing more. If you need a specific feature, you can open an issue and we can review how feasible this is.
I hereby officially invite you to become active in the project :-)

Also, it does not support Enignlement.

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 libdecor or the client application.

[jokeyrhyme]

Possibly a reference to the Enlightenment desktop/compositor, which does support client-side decorations in wayland: https://www.enlightenment.org/about-wayland

[rohmishra]

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:

• What's missing is a way for apps to read gtk-decoration-layout easily. But once apps can read that, apps can replicate (with a bit or rework and code sharing between Linux left side decoration/mac and right side/windows) button layout and apps should feel more in line with native apps as far as layout goes. (Or is it possible just never done?)
• there still are edge cases for buttons outside of the standard close, minimize, restore or systems like elementary which has button on both sides where apps need to have more flexible solution for their headers.
• this only works for apps that have window decorations mixed with their layout and apps are explicitly responsible for placing them like vscode but not apps that usually have system draw decorations for them (native window frame in vsc and other apps/almost all electron apps currently on Linux) so electron still needs to ship something (eg. libdecoration) to draw the buttons for those apps behind the scenes.
• developers still have to implement it or use a library that does most of the heavy lifting for them especially if they plan to support more exotic decoration config or using system assets for buttons

[WhyNotHugo]

@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.

[ZanderBrown]

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

Except Wayland (and yes Wayland not GNOME), so a no-go

[WhyNotHugo]

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.

[ZanderBrown]

Wayland itself support SSDs just fine.

No it doesn't, the Wayland spec has no concept of decorations

[oscarkey]

To avoid going in circles about Wayland support for SSDs, please see the second comment in this thread: #27522 (comment)

[rohmishra]

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.

eg.

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.

[eternal-sorrow]

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

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.

[rohmishra]

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

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.

      A client can use this protocol to request being decorated by a supporting
      compositor.

      If compositor and client do not negotiate the use of a server-side
      decoration using this protocol, clients continue to self-decorate as they
      see fit.

It does seem that the protocol implies that decorations might not be implemented by compositor and apps should have some fallback regardless.

[jokeyrhyme]

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

[rohmishra]

@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.

[ZanderBrown]

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 gtk-decoration-layout I'm not sure it's A) worth the effort B) simpler than using GtkHeaderBar/GtkWindowControls

[kennylevinsen]

Yes [weston] implements just the core spec which doesn't include xdg-decoration. That's somewhat the point.

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:

1. Protocols supported by weston: https://gitlab.freedesktop.org/wayland/weston/-/blob/master/protocol/meson.build#L15
2. Protocols used by Gtk/Gdk: https://gitlab.gnome.org/GNOME/gtk/-/blob/master/gdk/wayland/meson.build#L47
3. Protocols used by Chromium: https://github.com/chromium/chromium/tree/master/third_party/wayland-protocols/unstable (note: contains non-upstreamed protocols despite the folder name)
4. Gtk/Gdk server-side decoration functionality: https://gitlab.gnome.org/GNOME/gtk/-/blob/master/gtk/gtkwindow.c#L3067, https://gitlab.gnome.org/GNOME/gtk/-/blob/master/gtk/gtkwindow.c#L2980 and https://gitlab.gnome.org/GNOME/gtk/-/blob/master/gdk/wayland/gdksurface-wayland.c#L2248. gtk_window_set_decorated(win, FALSE) or gtk_window_set_titlebar(win, NULL) will enable server-side decorations.
5. Discussion about changing the stable/unstable separation and protocol maturity flow: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/30

[WhyNotHugo]

Looks like this is a duplicate of #27016