Button placement key

[orowith2os]

Closes #956

This only handles the layout of window decorations, the window decorations visuals themselves would probably best be handled separately, if at all.

Client implementations:

• GTK
• QT
• Electron + ArmCord
• Firefox

Portal implementations:

• GNOME: https://gitlab.gnome.org/GNOME/xdg-desktop-portal-gnome/-/issues/95
• KDE: https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/issues/14
• Cosmic, maybe?
• Pantheon: Window decorations key on Settings portal elementary/portals#87

[orowith2os]

I'm not entirely sure why workflows are failing, help would be appreciated there.

[orowith2os]

I made https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/200 to add the appropriate mode to xdg-decoration.

[orowith2os]

Update: still waiting on more input on how I should define this. The Wayland merge request is also useless here, was just a misunderstanding; server-side means apps shouldn't draw decorations at all, client-side means apps should draw them themselves. A none mode wasn't needed.

[orowith2os]

Going to update and rework this just a bit, since I've learned quite a bit more about how the GTK preference works and cross-toolkit-ness.

[jadahl]

This seems fine to add to me, it could be useful for hide e.g. minimize where it doesn't matter etc. What I'd like to point out is that it won't solve potential "annoyances" that people have with CSD apps hiding things so they can get another "frame" placed around them. Arguably the value for this settings entry in those DE:s should still be so that CSD-only applications can, if they want, add the appropriate window controls, so that if the DE uses the "minimize" concept a lot, the app knows it should add a minimize button. Maybe this was something you already had in mind already.

[swick]

The description of the setting is probably too strong. It tells clients exactly which buttons should be drawn in which order. It would probably be make more sense for it to be a hint: these actions make sense in the current environment. And then let the client figure out where to draw what buttons.

That also sidesteps issues with RTL layouts.

[orowith2os]

It would probably be make more sense for it to be a hint: these actions make sense in the current environment. And then let the client figure out where to draw what buttons.

I was thinking about this when reimplementing the button-layout logic from Tweaks, and yeah, a list of ideal actions would be better. I do think telling them where they should be drawn should be done though, so that on Pantheon you can get a close button on the left and on GNOME you get a close button on the right - while having no decorations on Sway and all decorations on the right on KDE.

[orowith2os]

Updated, and accounted for some potential configurations such that they're invalid, when they would be valid before.

Now it should work for setups such as: Sway, KDE, Pantheon, and GNOME.

[orowith2os]

Docs are finally building! Glad to see it making some more progress forward from where it was last time.

[lleyton]

Generally looks okay, at least from a quick look over. Personally, I'd use an int enum to represent the button types, but that's just bikeshedding from my part :p

[orowith2os]

@ebassi would you mind giving this an updated review, please? I'd like to see if there's anything else to nab before I start implementing it.

[orowith2os]

Bugged @danirabbit on the Elementary Slack about it, so I think Elementary can be considered mostly neutral or in favor of this - they'd just hardcode (["close"],["maximize"]) on their side of things. Here's a portal issue for them: elementary/portals#87

Someone needs to handle it for KDE too: https://invent.kde.org/plasma/xdg-desktop-portal-kde/-/issues/14

GNOME should be more or less fine, but someone needs to first expose a ([],["close"]) on the GNOME portal, then can possibly look at converting the gsettings key to that.

GTK should be able to implement the client side of this without adding or breaking the API.

[ilya-fedin]

btw, only GTK from client implementations mentioned in the PR seems realistic as both Firefox and Electron would rather use GtkSettings I believe and Qt has no concept of titlebar settings. Qt has only a dummy decoration for the cases when xdg-decoration is not present but then it's better to spend time on adding libdecor support I believe what ends with GTK client implementation again.

[jadahl]

@orowith2os don't merge main into this branch, this repository uses a linear history.

[orowith2os]

Fair enough, I can force push such that there's only one commit if/when this is ready to be merged :)

[jadahl]

Fair enough, I can force push such that there's only one commit if/when this is ready to be merged :)

Just do so now, no reason to wait to clean up the branch.

[orowith2os]

Done.

[jadahl]

Next step before this can land would be to create proof of concepts and "acks" in "enough" toolkits.

[orowith2os]

I'm sure @lleyton should be able to handle the tauOS and libhelium side of things, and the work can easily be strapped onto the GNOME portal + GTK with @ItsJamie9494. I plan on making a Rust representation and reference for the GNOME portal soon, and tauOS can reuse it in their stuff.

[ItsJamie9494]

I can work with GTK and GNOME, but I have nothing to do with libhelium and/or tauOS anymore

[jadahl]

What about Qt (and/or https://github.com/FedoraQt/QAdwaitaDecorations)? If it's GTK land only, then it's not gaining much compared to just forwarding the GTK gsetting, does it not?

Edit: wrong link to QtADwaitaDecorations.

[jadahl]

Sorry, sent the wrong link to QtAdwaitaDecorations.

[orowith2os]

I don't have anybody at hand to manage QT, but AFAIK that's all done with the platform plugins. You'd need to go through and update each one individually.

If I/we can sort something out for a source code representation of this setting, I can release it as a library and reuse that, possibly. Or use it as a base for other implementations.

[jadahl]

I don't have anybody at hand to manage QT, but AFAIK that's all done with the platform plugins. You'd need to go through and update each one individually.

That's why I linked to QtAdwaitaDecorations. See https://jgrulich.cz/2023/08/22/qt-theming-in-fedora-workstation/.

If I/we can sort something out for a source code representation of this setting, I can release it as a library and reuse that, possibly. Or use it as a base for other implementations.

"implementing" the setting is most likely 99% toolkit specific plumbing, so prototyping a library outside of a toolkit likely isn't much help - I don't imagine GTK or Qt would have any use for it.

[grulja]

In QAdwaitaDecorations I already use what's provided by org.gnome.desktop.wm.preferences (in particular button-layout key). There is not much I can gain changing that for something else since this project targets GNOME and this is expected to be provided all the time. For Qt in general, I can imagine this being part of the decoration plugin.

[orowith2os]

QAdwaitaDecorations should probably still look to use this portal at some point, in the (possibly unlikely) event it's used someplace that's not GNOME, and the GNOME preferences aren't available to be read.

[orowith2os]

@ebassi @jadahl do you both have any thoughts on other paths this could take? anything nicer to expose over dbus? anything that's easier to put into code? it is Not Fun™ as-is.

[ilya-fedin]

You'd need to go through and update each one individually.

The proper way would be to add a hint here, then implement it here and consume in decoration plugins like this (the default one is here)

    if (const QPlatformTheme *theme = QGuiApplicationPrivate::platformTheme()) {
        const QVariant themeHint = theme->themeHint(QPlatformTheme::SystemIconThemeName);
        if (themeHint.isValid())
            return themeHint.toString();
    }

The one who would like to implement this will probably have to have a talk about that at development@qt-project.org mailing list first.