-
-
Notifications
You must be signed in to change notification settings - Fork 196
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
Button placement key #996
base: main
Are you sure you want to change the base?
Button placement key #996
Conversation
I'm not entirely sure why workflows are failing, help would be appreciated there. |
I made https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/200 to add the appropriate mode to xdg-decoration. |
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. |
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. |
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. |
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. |
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. |
70077f4
to
d0afdae
Compare
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. |
d0afdae
to
851067e
Compare
Docs are finally building! Glad to see it making some more progress forward from where it was last time. |
851067e
to
0086ced
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
@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. |
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 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 GTK should be able to implement the client side of this without adding or breaking the API. |
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. |
@orowith2os don't merge main into this branch, this repository uses a linear history. |
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. |
Signed-off-by: Dallas Strouse <[email protected]> Co-authored-by: Emmanuele Bassi <[email protected]>
f75ffdb
to
19ba62b
Compare
Done. |
Next step before this can land would be to create proof of concepts and "acks" in "enough" toolkits. |
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. |
I can work with GTK and GNOME, but I have nothing to do with libhelium and/or tauOS anymore |
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. |
Sorry, sent the wrong link to QtAdwaitaDecorations. |
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. |
That's why I linked to QtAdwaitaDecorations. See https://jgrulich.cz/2023/08/22/qt-theming-in-fedora-workstation/.
"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. |
In QAdwaitaDecorations I already use what's provided by |
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. |
<term>org.freedesktop.appearance button-placement (asas)</term> | ||
<listitem><para> | ||
Indicates the system's preferred arrangement of buttons on the titlebar. | ||
In LTR locales, the first tuple is on the left (leading), and the second tuple is on the right (trailing). | ||
In RTL locales, the first tuple is on the right (leading), and the second tuple is on the left (trailing). | ||
Supported values are: | ||
<simplelist> | ||
<member>close: the close button</member> | ||
<member>minimize: the minimize button</member> | ||
<member>maximize: the maximize button</member> | ||
</simplelist> | ||
Unknown values must be ignored if the client does | ||
not understand them. Duplicate buttons across the tuples and | ||
string arrays are not allowed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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)
The one who would like to implement this will probably have to have a talk about that at [email protected] mailing list first. |
@grulja |
Sure it is, you can get it through the settings portal already and it doesn't make a difference whether you make the call inside or outside the sandbox. I'm using it here for example. |
Huh, that's interesting. The portal documentation says
And then goes on to list Now I'm wondering if this is on purpose or a mistake. |
None of those settings provided via xsettings btw. org.gnome.desktop.wm.preferences.button-layout is provided (Gtk/DecorationLayout). And if it really provided only those keys, gtk applications weren't following lots of settings such as font name/size, cursor theme/size. |
As @tytan652 pointed out to me, the docs also say
but I completely missed it. |
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:
Portal implementations: