GNOME Bugzilla – Bug 729784
Decoration buttons do not follow custom specified layout in desktop environment
Last modified: 2018-05-02 16:06:27 UTC
Created attachment 276131 [details] Wrong close button position Some desktop environments (like Plasma) allow to specify the layout of window decoration buttons. GTK+ applications do not honor these settings, making them being the odd spot when the general close button is on the left. Steps to reproduce: 1. Run Plasma session 2. Configure window decoration to have close button on the left 3. Start gtk3-demo Actual Result: close button is on the right Expected Result: close button is on the left See the attached screenshot highlighting the issue using the double decorated on non-compositing bug (see bug 729769).
You'll need a bit of glue code in your xsettings manager to translate your own setting into the right Gtk/DecorationLayout setting. See https://git.gnome.org/browse/gtk+/tree/gtk/gtksettings.c#n1549
erm, that's not really a solution for our stable (4.11, released July 2013) release. We cannot just add new code there.
also that's lacking quite a lot buttons. I'm missing: * on all desktops * shade * keep above * keep below * quick help * layout spacers
I would accept a patch that allows buttons for things which already have gdk api (on all desktops, keep above, keep below fall in that category). I'm not interested in supporting shade with csd. No idea what quick help and layout spacers would do...
What can we do on the GTK+ side to help with this?
(In reply to comment #5) > What can we do on the GTK+ side to help with this? I think this needs standardization to have the window manager expose the expected button order and GTK+ reading this from root window. I don't have a problem with exposing that information from KWin, but we cannot feed into some custom GTK settings for which we don't have any code.
(In reply to comment #6) > I think this needs standardization to have the window manager expose the > expected button order and GTK+ reading this from root window. I don't have a > problem with exposing that information from KWin, but we cannot feed into some > custom GTK settings for which we don't have any code. XSettings is basically a standard root window property. Have you read http://standards.freedesktop.org/xsettings-spec/xsettings-latest.html ?
I don't understand that inability to use xsettings - seems made-up to me.
there are two problems from our side here: * we don't have any xsettings related code in KWin, we would need to add it * we don't set GTK (or any other Client specific including KDE) settings from our side. We need to have that standardized. Of course it would be possible to set the GTK settings, but there is no guarantee that this wouldn't break, it's outside of our control and is also something which smells like bit rot - if GTK switches the mechanism we wouldn't notice and the code would stay. We don't do client specific things in KWin at all. That's why I think it needs to be standardized through NETWM hints. Defining all possible buttons (and not just those GTK knows) and exporting them. This would be easy on our side and would also allow other non-GTK applications to use it (think of Chromium for example).
My suggestion is to try to standardize the following: * _NET_DECORATION_BUTTON_GROUP_LEFT * _NET_DECORATION_BUTTON_GROUP_RIGHT Both as an array taking values of: * _NET_DECORATION_BUTTON_WINDOW_MENU * _NET_DECORATION_BUTTON_APPLICATION_MENU * _NET_DECORATION_BUTTON_MINIMIZE * _NET_DECORATION_BUTTON_MAXIMIZE_RESTORE * _NET_DECORATION_BUTTON_CLOSE * _NET_DECORATION_BUTTON_MOVE * _NET_DECORATION_BUTTON_RESIZE * _NET_DECORATION_BUTTON_STICKY * _NET_DECORATION_BUTTON_KEEP_ABOVE * _NET_DECORATION_BUTTON_KEEP_BELOW * _NET_DECORATION_BUTTON_SHADE * _NET_DECORATION_BUTTON_HELP Would you add support for something like that? If yes then I'm going to start drafting an update for the NETWM spec.
The issue with this is that if we see both the root window property and XSettings, which one do we obey? I don't know why you can't implement XSettings, as it was designed for this. Also, what do we do when clicking the HELP button? mutter and GTK+ don't have support for a HELP button. I'm also not quite sure what MOVE / RESIZE buttons does. Do they trigger on release and start a keyboard-initiated move/resize?
(In reply to comment #11) > The issue with this is that if we see both the root window property and > XSettings, which one do we obey? sorry, cannot help you there :-) > I don't know why you can't implement XSettings, as it was designed for this. I think that's obvious: we don't set client-specific settings. If we do that for GTK, we would also have to set it for Chrome, Opera, Steam, etc. etc. For each client a different way of setting those hints and having to hunt down changes. No thank you, not interested in that :-) Also from looking at the implementation in GTK+ only a small subset of the buttons provided by KWin are supported. If we are going to set export buttons we want to export all. Not that it ends in becoming a de-facto standard and implementations supporting more than GTK's buttons not adding those because they are not exported. If we go to invest time in providing this for client-side-decorated clients it has to be a standard. I expect the same is true for all window managers and I doubt that you expect the developers to read GTK+ source code to figure out how to set this for GTK. If it's in the spec it's obvious on how to do it. > > Also, what do we do when clicking the HELP button? mutter and GTK+ don't have > support for a HELP button. That's fine, then don't show it. Obviously we cannot force Clients to support each type of buttons. The help button triggers the context help which is NET_WM_CONTEXT_HELP but apparently is lacking in the spec which just surprised me. Google provides me some discussion: https://mail.gnome.org/archives/wm-spec-list/1999-December/msg00008.html > I'm also not quite sure what MOVE / RESIZE buttons > does. Do they trigger on release and start a keyboard-initiated move/resize? Like all buttons on release. But to be fair KWin doesn't have a move button and resize button is not provided by any window decoration. So we only have partial support for it. I just wanted to write down all actions I could think of.
(In reply to comment #12) > I think that's obvious: we don't set client-specific settings. If we do that > for GTK, we would also have to set it for Chrome, Opera, Steam, etc. etc. For > each client a different way of setting those hints and having to hunt down > changes. No thank you, not interested in that :-) XSettings is not a GTK+ or GNOME-specific thing. It is implemented and supported by other desktops like XFCE and Unity as well. There's a standard for it: http://standards.freedesktop.org/xsettings-spec/xsettings-latest.html There's available code for it. http://git.xfce.org/xfce/xfce4-settings/tree/xfsettingsd/xsettings.c https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/xsettings/gsd-xsettings-manager.c The issue here, I think, is that we use the key name "Gtk/DecorationLayout", but that's two lines to change, instead of rewriting the entire infrastructure. Much like the _GTK_ prefix, we just wanted to get a feature out the door without having to go through a standardization process, as the "Net/" prefix is only for standardized settings. I'd be fine with changing that to "Net/DecorationLayout". I don't think there's an XSettings standardization process anymore, though, only a wiki page. So if one of us just writes a few blobs of text on a wiki page... :) > That's fine, then don't show it. I was mostly curious what the non-obvious buttons did, so I could add support for them. > The help button triggers the context help which is > NET_WM_CONTEXT_HELP but apparently is lacking in the spec which just surprised > me. Google provides me some discussion: > https://mail.gnome.org/archives/wm-spec-list/1999-December/msg00008.html Thanks, I wasn't aware of that. Obviously, since GTK+ never has it in its supported actions, we'll never respond to that protocol anyway, so we just won't show the button :)
(In reply to comment #13) > (In reply to comment #12) > > I think that's obvious: we don't set client-specific settings. If we do that > > for GTK, we would also have to set it for Chrome, Opera, Steam, etc. etc. For > > each client a different way of setting those hints and having to hunt down > > changes. No thank you, not interested in that :-) > > XSettings is not a GTK+ or GNOME-specific thing. It is implemented and > supported by other desktops like XFCE and Unity as well. There's a standard for > it: > > http://standards.freedesktop.org/xsettings-spec/xsettings-latest.html That looks like not being a standard: "cross toolkit configuration *proposal*" > > There's available code for it. > > http://git.xfce.org/xfce/xfce4-settings/tree/xfsettingsd/xsettings.c > https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/xsettings/gsd-xsettings-manager.c > > The issue here, I think, is that we use the key name "Gtk/DecorationLayout", > but that's two lines to change, instead of rewriting the entire infrastructure. > Much like the _GTK_ prefix, we just wanted to get a feature out the door > without having to go through a standardization process, as the "Net/" prefix is > only for standardized settings. I'd be fine with changing that to > "Net/DecorationLayout". I don't think there's an XSettings standardization > process anymore, though, only a wiki page. So if one of us just writes a few > blobs of text on a wiki page... :) all right that makes more sense then. Nevertheless we don't have any XSettings code in KWin and I am not aware of any XSettings code anywhere in KDE source base - might exist, might not. If we don't have any code, it's unlikely that we will be able to export this any time soon. Investing lots of time for X11 when I am supposed to work on Wayland is problematic. So from our side using just a property would be way easier than first implementing support for xsettings.
Just did some investigations on xsettings in kde: there is some dead code in playground and apparently some distros used to ship it. But it has always been just a downstream thing. This means from the upstream point of view: there is no xsettings support in our software. Sorry doesn't sound like we will be able to do this through xsettings.
Also using an xsettings-daemon wouldn't work for us. It's KWin which needs to provide how the buttons order looks like - not some configuration file a daemon could parse. From our implementation the setting is only a "recommendation" to the window decoration plugin. This plugin might use a completely different one. To properly support announcing the button order we would have to change the API to pass back to KWin how the actual order looks like. This means it's a runtime property and not a configuration value ever written to a backend store. To me it's like the names of the virtual desktops which are also read from a root window property and not from a setting. This means I think that using xsettings at least from KWin point of view is unsuited and I'd rather prefer just using a property on the root window.
(In reply to comment #16) > Also using an xsettings-daemon wouldn't work for us. It's KWin which needs to > provide how the buttons order looks like - not some configuration file a daemon > could parse. you misunderstand what XSETTINGS is, then. the XSETTINGS protocol describes how to describe and share configuration settings; it does not describe storage. GTK+ reads the properties through an XSETTINGS client and reacts accordingly; KWin would expose those properties using the XSETTINGS protocol. instead of creating a new, separate protocol of properties, you should use the XSETTINGS protocol, which was created with this intent and purpose more than 10 years ago. not really anybody's fault if KDE decided to ignore it.
(In reply to comment #17) > (In reply to comment #16) > > Also using an xsettings-daemon wouldn't work for us. It's KWin which needs to > > provide how the buttons order looks like - not some configuration file a daemon > > could parse. > > you misunderstand what XSETTINGS is, then. > > the XSETTINGS protocol describes how to describe and share configuration > settings; it does not describe storage. from what I understand there needs to be a manager selection which should be hold by a daemon. If we could just set the property without having to claim manager selection or first starting a daemon then it's no problem. But my understanding given the specification is different and we cannot just claim the selection from KWin as that would break any maybe existing running daemon. > not really anybody's fault if KDE decided to ignore it. that's not helpful at all - pointing fingers doesn't solve the problem. The situation right now is that GTK wants to use it, but we at KWin don't have a way to interact with it.
Just wondering: is there a way to write this to a configuration file? We do have a KCM for configuring GTK details. I could add there an interaction with KWin to store the settings for buttons there. I tried to investigate a little bit on why KDE doesn't support XSettings. All I could find is a mailing list thread from 2005 where KDE devs wondered about that as well. Qt 5 has some code nowadays to be a client. If it's possible to just write the property without needing a daemon I could probably reuse the code to set the property. Still I think it will be difficult to get that through code review as that will be considered as too specific for GTK's need to set it from KWin. Again just having a NETWM property like for everything else related to window managers and client interaction would be way easier from our side and everybody else who doesn't support xsettings yet (git grep -i xsettings on i3 didn't list anything).
I'd be fine with adding support for the root window property if it's really such a big pain for you.
(In reply to comment #20) > I'd be fine with adding support for the root window property if it's really > such a big pain for you. that's much appreciated! I guess it would make sense that Plasma uses xsettings to make GTK applications integrate better, but that's kind of out of scope for KWin and would also not solve the problem for KWin (we do not exclusively target Plasma, but are also quite commonly used by LXDE and XFCE users - which sometimes surprises me quite a bit ;-). I'll try to look into this for Plasma 5.1.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/489.