Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Settings portal: WindowDecorations key #956

Open
orowith2os opened this issue Jan 19, 2023 · 7 comments · May be fixed by #996
Open

Settings portal: WindowDecorations key #956

orowith2os opened this issue Jan 19, 2023 · 7 comments · May be fixed by #996
Labels
needs discussion Needs discussion on how to implement or fix the corresponding task new api This requires adding API to an existing portal

Comments

@orowith2os
Copy link

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
Copy link
Contributor

grulja commented Jan 20, 2023 •
edited
Loading

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
Copy link
Author

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 orowith2os linked a pull request Mar 29, 2023 that will close this issue
Open
8 tasks
@orowith2os
Copy link
Author

@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
Copy link
Member

TingPing commented May 5, 2023 •
edited
Loading

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
Copy link
Author

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
Copy link
Member

TingPing commented May 5, 2023 •
edited
Loading

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
Copy link
Author

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

@GeorgesStavracas GeorgesStavracas moved this to Needs Triage in Triage Oct 2, 2023
@GeorgesStavracas GeorgesStavracas added new api This requires adding API to an existing portal needs discussion Needs discussion on how to implement or fix the corresponding task labels Oct 3, 2023
@GeorgesStavracas GeorgesStavracas moved this from Needs Triage to Triaged in Triage Oct 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
needs discussion Needs discussion on how to implement or fix the corresponding task new api This requires adding API to an existing portal
Projects
Triage
Status: Triaged
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Button placement key orowith2os/xdg-desktop-portal
4 participants
@TingPing @grulja @GeorgesStavracas @orowith2os