Settings portal: WindowDecorations key

[orowith2os]

Currently the state of window decorations on Linux is a bit weird, with X11 having SSDs, Wayland not requiring SSDs and applications ignoring the lack of xdg-decoration support, or applications that draw client side decorations (like libadwaita apps, or Chrome/ium, Firefox) not following some system themes.

Having a WindowDecorations key can be useful to specify if the user wants the close/max/min buttons to show, and whether or not they should show on the left or right sides of the application headerbar.
I don't believe this would be good as a Wayland or X11 protocol, but rather something independent of the display server.

On top of the main three buttons, maybe a Titlebar option too? So that compositors that don't implement xdg-decoration (but don't want CSDs) can disable it there.

Additionally, maybe this could include a filesystem link to some SVG files to be used for the icons (/run/user/UID/theme/close.svg)? This part might be out of scope, and applications might not agree on this part.

This could be done alongside org.freedesktop.appearance.color-scheme, as org.freedesktop.appearance.windowdecorations.

color-scheme: https://github.com/flatpak/xdg-desktop-portal/blob/main/data/org.freedesktop.portal.Settings.xml#L32

[grulja]

This is already sort of provided by xdg-desktop-portal-[gnome/gtk], where one can read button-layout property from org.gnome.desktop.wm.preferences. I use it with my CSD implementation in QGnomePlatform. In KDE you don't need this because it supports SSD. And the only remaining portal backend implementation xdg-desktop-portal-wlr doesn't seem to implement the settings portal.

The "titlebar" option you mention, I think this is already something specified and communicated by the Wayland decoration protocol.

Even though I think this might be a good thing to have, I'm unsure if it would be used somewhere else besides GNOME where this is already available, but I might be wrong.

[orowith2os]

The idea of having it in the core portal is so that its independent from the desktop. And even when SSDs are supported, apps can still draw their own decorations; GTK apps and Steam do this.
Its especially useful for if/when Linux moves closer to the mobile space, as mobile shells might not want window controls or a title bar if their shell doesn't implement xdg-decoration.

[orowith2os]

@grulja made #996, check that if you'd like to see the current take on it. It's heavily based off of the button-layout property from GNOME.

[TingPing]

I largely agree with @grulja. Adding a setting here isn't for an "if/when" use-case. We should have real world examples of non-GNOME toolkits/platforms wanting/able to use this. Otherwise the, kinda private to GNOME, setting already works for GNOME.

[orowith2os]

non-GNOME toolkits/platforms wanting/able to use this.

On the Wayland GNOME session, all clients must draw decorations themselves. Unless they use GTK/libdecor or directly read the gsettings key, which not everyone would like to do, you have a mismatch of decoration buttons across GTK and non-GTK clients.

KDE would want this to tell GTK apps (and others) to draw the full decoration set.

Standalone WMs and embedded systems would use xdg-decoration to tell clients not to tell decorations at all. But for those systems that want them to draw them (full DEs), this key is useful.

[TingPing]

KDE already directly sets various GSettings that GTK uses, so it could add one more, and you are expected to have xdg-desktop-portal-gtk installed for GTK usage in general.

I do agree other CSD apps could use it but these aren't very numerous. They should be involved to ensure its actually lused.

[orowith2os]

I'll add some clients that should implement this to the PR, and we can check those off as we go.