After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 729783 - Missing maximize and minimize buttons in client side decoration
Missing maximize and minimize buttons in client side decoration
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: Other
3.12.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks: CSD
 
 
Reported: 2014-05-08 06:48 UTC by Martin Gräßlin
Modified: 2015-03-08 00:14 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Martin Gräßlin 2014-05-08 06:48:44 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
Comment 1 Giovanni Campagna 2014-05-08 15:18:19 UTC
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.
Comment 2 Matthias Clasen 2014-05-11 14:05:50 UTC
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.
Comment 3 Martin Gräßlin 2014-05-11 14:39:10 UTC
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.
Comment 4 Allison Karlitskaya (desrt) 2014-06-25 16:44:21 UTC
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.
Comment 5 Matthias Clasen 2014-06-25 18:10:43 UTC
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.
Comment 6 Martin Gräßlin 2014-06-25 18:24:49 UTC
> 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.
Comment 7 Emmanuele Bassi (:ebassi) 2014-06-25 18:32:29 UTC
(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.
Comment 8 Allison Karlitskaya (desrt) 2014-06-25 19:22:59 UTC
(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...
Comment 9 Matthias Clasen 2014-06-25 21:34:28 UTC
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.
Comment 10 Martin Gräßlin 2014-06-26 06:24:47 UTC
(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"
Comment 11 Matthias Clasen 2015-03-08 00:14:02 UTC
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.