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 702971 - GtkHeaderBar - pick up window controls from the system settings
GtkHeaderBar - pick up window controls from the system settings
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: .General
3.9.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2013-06-24 12:55 UTC by Allan Day
Modified: 2013-08-04 23:39 UTC
See Also:
GNOME target: ---
GNOME version: 3.7/3.8


Attachments
GtkHeaderBar: optionally add a close button (13.91 KB, patch)
2013-08-04 09:01 UTC, Matthias Clasen
committed Details | Review

Description Allan Day 2013-06-24 12:55:23 UTC
Header bars for sovereign windows are supposed to contain the window controls. By default this is just the close button, but it is possible to change it - in this situation the header bar should pick up the window controls configuration from the system.

For example, if I add the minimise button to my window controls, it should also be added to the header bars.

Also note that, under certain circumstances, it is necessary to hide any window controls contained within the header bar (such as when selection mode is active).
Comment 1 Jeremy Bicha 2013-07-01 17:23:49 UTC
I'd like to see this feature support minimize, maximize and close on either the left or right sides of the window.

I don't understand why selection mode needs to hide the window controls.
Comment 2 Jakub Steiner 2013-07-02 13:10:39 UTC
The reason for selection mode not having close as it's potentially very close to canceling/dismissing selections and you want to avoid the frustration of closing the window.

I'm really not fond of bringing all these window controls to the headerbar. Unfortunately we didn't quite manage to not have a close button in there, but that doesn't mean we have to come full circle into having a full blown titlebar.
Comment 3 Allan Day 2013-07-02 19:52:32 UTC
(In reply to comment #2)

I hear you, Jakub. My only motivation for this bug was classic mode. :/
Comment 4 William Jon McCann 2013-07-02 21:36:55 UTC
I'm very strongly against this. A client side decorated application window should be designed and tested one way. It should not try to adapt itself.
Comment 5 Jeremy Bicha 2013-07-02 21:52:42 UTC
(In reply to comment #4)
> I'm very strongly against this. A client side decorated application window
> should be designed and tested one way. It should not try to adapt itself.

Then this feature is a regression from GNOME 3.8.

Will apps that use this feature have some sort of fallback for Unity, Cinnamon, Flashback, XFCE, etc. ?
Comment 6 Matthias Clasen 2013-08-04 09:01:47 UTC
Created attachment 250787 [details] [review]
GtkHeaderBar: optionally add a close button

Add a boolean property that controls whether a window close button
will be shown in the header bar or not. Doing this in the toolkit
will ensure consistency of the visual apperance.
Comment 7 Matthias Clasen 2013-08-04 23:39:09 UTC
Attachment 250787 [details] pushed as b38a096 - GtkHeaderBar: optionally add a close button