GNOME Bugzilla – Bug 729783
Missing maximize and minimize buttons in client side decoration
Last modified: 2015-03-08 00:14:02 UTC
When running a GTK application in a desktop environment still supporting maximize and minimize through window decoration buttons, the buttons are missing for GTK applications. Steps to reproduce: 1. Run a Plasma session 2. Observe that the default button layout is: window icon (menu), on all desktops on the left and minimize, maximize, close on the right 3. Start gtk3-demo Actual result: no minimize, maximize, on all desktops and menu button Expected result: all the expected buttons are supported especially as the features are provided through the context menu
GTK+ uses XSettings (Gtk/DecorationLayout) to find out which buttons are to be shown and on which side. I thing the xsettings plugin of kded should mirror the kwin config to gtk.
Giovanni is right; this can be controlled via the xsetting he mentions. Note that you won't be able to configure actions other than minimize, maximize, menu and close. A patch to add 'on all desktops' would be considered - we already have gdk api for it, after all.
I don't think that using xsettings is an appropriate solution. It's clearly not a solution for our stable release 4.11 which got released last July and is in deep feature freeze. Furthermore I don't think it's a good solution if we write GTK internal settings. This needs to get standardized through NETWM, so that we can just export the buttons. We don't want to have mapping code to all possible toolkits and especially not to have to update it whenever a new button gets introduced or an existing renamed. This just doesn't scale.
Obvious alternative: we could change the default behaviour of Gtk to be similar to "classic desktop environments" and look for the key, which we know GNOME will indeed be setting to tell us to do it the GNOME way.
The cost will be that we look unpolished, e.g. at shutdown when g-s-d dies early, and all remaining windows suddenly change their window decorations because the setting reverts to its default. You can argue that thats a problem in the way the session teardown currently works. And it may be, but it doesn't matter for the outcome: we'll make our own stuff look worse.
> we could change the default behaviour of Gtk to be similar to "classic desktop environments" and look for the key That is probably a better default, but doesn't solve the problem. Those "classic" desktop environments like Plasma have multiple shells which have different button settings for those "classic" things like a netbook optimized interface, a media center or a touch interface. Also for those "classic" things like tiling window managers it's still a problem that the window is decorated at all. > we'll make our own stuff look worse. I always thought GTK is a multi-platform toolkit?!? How can it be that GNOME Shell is considered as "own stuff" and that possible crashes (that is bugs) in GNOME Shell are more important than integration with other platforms.
(In reply to comment #6) > I always thought GTK is a multi-platform toolkit?!? GTK+ is not Qt. while GTK+ supports multiple platforms, being "multi-platform" for the sake of it is a non-goal of GTK+. > How can it be that GNOME > Shell is considered as "own stuff" and that possible crashes (that is bugs) in > GNOME Shell are more important than integration with other platforms. crashes *anywhere* are more important than integration with other platforms, regardless of the platform. integration with GNOME (not GNOME Shell) also fares fairly high on the list of requirements.
(In reply to comment #5) > The cost will be that we look unpolished, e.g. at shutdown when g-s-d dies > early, and all remaining windows suddenly change their window decorations > because the setting reverts to its default. You can argue that thats a problem > in the way the session teardown currently works. And it may be, but it doesn't > matter for the outcome: we'll make our own stuff look worse. This is a pretty weak argument and I'm surprised to see it here. It's not like this is the only problem that we'd notice: how about a flicker of an appmenu fallback or (until very recently) the theme disappearing. More to the point, though: I can't remember the last time I saw either of those things happen...
Martin, I'm not going to reply to comments from you anymore if you just use this to look for material for smear campaigns. Good job torpedoing any chance of cooperation.
(In reply to comment #9) > Martin, I'm not going to reply to comments from you anymore if you just use > this to look for material for smear campaigns. Good job torpedoing any chance > of cooperation. sorry, but this made me really frustrated to read it. I should not have needed to invest the time to report the bugs here - the regression testing is something you (as in GTK developers) should have done (it took me several hours to report those issues at a time where we had enough own regressions to work on). I'm willing to implement hooks in KWin to make it work better - again that is something which should not be needed. In fact it should not be that GTK+ is basically forcing all window managers to add code to make the new client side decorations work. I doubt that projects except KWin have the man power to do so. If one is willing to invest time to improve the situation for your apps - I really have better things to do, it's really frustrating to then see your perspective. A flicker is more important than saner defaults. Just think how that must feel on my side when I just try at the same time to hurry a last minute ABI change into frameworks to make GTK apps work better. If you consider my post on Google+ as a "smear campaign" I'm sorry, that was neither my intend nor do I think that a single one comment about GTK can be considered a campaign. It was a sign of the frustration I have with the situation of the client side decorations. > Good job torpedoing any chance of cooperation. Like I will continue to try to improve the situation, I do hope that you will also continue to work on improving the situation. Those are our all users. Again sorry, that was coming from frustration. I had a great day yesterday till I read your comment. It just destroyed all hope that the situation would improve and it pulled down my mood a lot. Maybe I need to work on myself to not post that on Google+ then... > (In reply to comment #6) > > > I always thought GTK is a multi-platform toolkit?!? > > GTK+ is not Qt. while GTK+ supports multiple platforms, being "multi-platform" > for the sake of it is a non-goal of GTK+. maybe update your gtk.org web site then ;-) "GTK+, or the GIMP Toolkit, is a multi-platform toolkit"
The defaults have been changed way back last summer: https://git.gnome.org/browse/gtk+/commit/?id=1cd9ba187e418bbc90b5724142f299b0be0f5425 As for xsettings not being appropriate and netwm standardization, we can adapt the code when such standardization appears.