It is also inconsistent with other settings (like middle-, right- and double-click on the bar).
It looks like these functions are hardwired, the keyboard shortcuts instead work like expected.

The new design looks great, but for the people that like to tweak the environment to their liking it'll probably be just a headache.

In my opinion, the big issue with this is that GTK+ can't be a toolkit for just the GNOME desktop or it'll die.

The designers behind desktop environments such as elementary's Pantheon and XFCE have decided that they prefer the close button to be on the left. GNOME has them on the right. Problem? I don't think so. Windows has them on the right and Mac OS X has them on the left. (I actually believe the user should be able to choose right or left, but that's a whole different debate, not even related to this one.)

As I was saying, those desktop environments have them on the left. With the recent addition of GtkHeaderBar to GTK+, due to its advantages (and let's admit it, it's sexy and I've wanted it for as long as I've seen mockups from elementary OS designers with it), developers of a variety of applications will start using them. Problem? No.

So let's settle on something - ultimately, none of us wants users of GTK+ applications to have some windows with the button on the right side and some windows with button on the left side. I really hope you want the same as I do - the best for the users.

Then what needs to happen is that GtkHeaderBar follows the dconf/gconf keys for the WM buttons (org.gnome.desktop.wm.preferences button as mentioned by the bug reporter). Why? Say I'm an elementary OS user and I found this new application that I really need and like. I install it and it seems to use the GtkHeaderBar which has the Close button on the right. "Damn it, all my other windows have it on the left, this is kind of annoying". As far as I know, the same story goes for XFCE users and any user who has changed the dconf/gconf key.

(Also, I keep saying dconf/gconf key because I don't really know where it is, but I think it's dconf/gsettings).

Anyway, this seems obvious to me - GtkHeaderBar has to support this. However, when I noticed it didn't I suspected it was just a bug, as in, something that had to still be implemented. Actually, I was wrong. I went on the #gtk+ channel on the GNOME IRC Network and talked to @Company, who seems to be a GTK+ developer. He opposedly _strongly_ to this feature even when me and others tried to talk him into it. I don't know how much of a privacy issue this is but here are the logs of that day: http://pastie.org/8306970 (not complete logs, sorry but I don't have full).

I later private messaged @mclasen, who seems to be another GTK+ developer, (I won't post these logs here because they were private) and he also opposed to this vehemently. I was honestly shocked, he didn't see the point in this.

I've even seen GNOME users who change their buttons to the left because they're used to it or prefer it that way, who might have their desktop broken on a future update!

I can't find reasoning for this "decision" by the GTK+ team and it saddens me that the elementary OS team will have to _patch_ GTK+ and include a patched GTK+ version on their next release so both their native apps and any eventual 3rd party apps look right with this new GtkHeaderBar. Patching GTK+ is not something we really want to do, but see ourselves forced to do.

To sum up, I really hope you change your minds about it.

(if you just want to see my suggestion, jump to the last paragraph)

First of all, I think people should calm down.

In my personal opinion, the *principle* behind GNOME's stance on this is understandable. One might not agree with it, but dismissing it as "pointless" and screaming how GTK is "trying to suck" due to this ONE ISSUE, after YEARS of using EVERYTHING ELSE on the toolkit and liking it, sounds remarkably immature and ungrateful.

That said, I do agree with elementaryOS devs about the *implementation* of such principle being too rigid in this particular case. Window buttons *are* quite annoying to have in different positions depending on the window. I don't think this can be considered "minor", and an effort to avoiding this sounds worthy.

On the other hand, I agree with GNOME devs about a setting key being a PITA on maintenance, theming, and consistency levels.

The only way I see this discussion going forward is making it flexible. I don't see any reason for believing following dconf is "what needs to happen". There are other options available, like environment variables. The public method proposal is interesting, but still leaves the burden to app devs, which is less than ideal.

In particular, I'm *very* interested in knowing what the maintainers of the OSX branch of GTK have to say on this.

tl;dr

I don't know if this is even possible to implement, but my personal suggestion is shifting the button position to the *theme*, as part of the GtkHeaderBar style. That would force theme devs to align the visual with a specific position, and force them to be aware of this regardless of DE.

(In reply to comment #3)

> I don't know if this is even possible to implement, but my personal suggestion
> is shifting the button position to the *theme*, as part of the GtkHeaderBar
> style. That would force theme devs to align the visual with a specific
> position, and force them to be aware of this regardless of DE.

while off-loading this to the theme would be a sensible option, especially for other platforms, there is the proximal problem that the CSS cannot control the layout of the UI, as well as the distal problem of having to test that CSS anyway.

as for the issue of GtkHeaderBar on MacOS (or Windows), we can simply have a platform check that flips the order of the buttons, and/or shows all three of the close/maximize/minimize buttons; that is actually the path of least effort for us, even if there's a QA issue there as well.

I have to agree with Benjamin and Matthias: having yet another setting means adding yet another branch in the code path — and yet another row in the testing and QA matrix, something we currently cannot afford in the least. while we do continuous integration on GNOME, we are not able to do that for MacOS and Windows — let alone other environments on Linux like XFCE and Elementary. hence the reluctance at adding another potential point of failure.

I'm open to suggestions as to how this should be implemented, in terms of themeing and platform detection. simply deferring it to a setting is definitely not interesting to me.

As far as I understand, simply deferring it to a setting is what spares you the doom of writing platform detection in GTK itself and then testing it on every single platform there is.

Shnatsel, if the key exists, so does an implicit compromise of ensuring that all possible settings of this key work in all possible platforms. Unless you want to explain to all power users and all developers of tweak tools that the default theme sucks with buttons on the other side because you're not supposed to change the key and thus that case was not tested.

As I see it, this is precisely the crux of the matter: full configurability is a solution to something much larger than the actual problem (platform-specific configurations). Something that most people won't care enough to use. Not only this is conceptually wrong, that's also how bits start to rot.

This key has existed for quite some time now and it always worked fine.

David, you missed the point on two levels:

1) The key exists, but the code to implement its effects on GTK does not.

2) The key does not work fine, and never did. There has always been themes that assumed an specific button placement, and completely sucked when the order was changed. And frankly, I always thought this was acceptable. Theme developers have no obligation no satisfy all possible settings of all possible keys.

I'd like to record here that I don't agree to the characterization of our private conversation as me 'opposing vehemently'. Reading back, I can't see a single line on mine that could have been interpreted that way. Please don't mischaracterize what I said - feel free to post the logs.

In fact, I wrote code to interpret a decoration-button-layout style property in GtkWindow when simulating traditional titlebars for CSD. Whether application-constructed header bars should pay attention to that or some other platform setting, or not is a separate question.

"The key does not work fine, and never did. There has always been themes that
assumed an specific button placement, and completely sucked when the order was
changed."
I imagine such themes will profilerate wildly if you ditch the configurability, because to test a theme on a different button layout the designer would have to install another freaking DE instead of simply changing a setting.

Regarding QA procedures, you can check if a settings key is being followed or not in a platform-independent code and test it on just one platform. 
This is much better than writing platform detection code and checking if it works *on each platform*, then writing platform-specific test cases for actually changing the button layout.

Also I feel the bug title kinda mis-represents the problem. 

It's not "We want the settings key back please please please!", it's "Applications using GTK HeaderBar do not follow the button layout convention of the DE they run in". 
DEs affected include Mac OS, XFCE, Ubuntu/Unity and elementary/Pantheon.

And, don't get me wrong, I am not a proponent of ubiquitous configurability. I'm actually on the "Don't defer to configuration" camp. A settings key just looks like the easiest way to solve the "Apps inconsistent with the DE" problem. 
Putting platform detection code in GTK itself looks too inflexible and difficult to test, public method proposal seems to defer the problem to application developers which I don't find acceptable, and deferring to the theme (in the current form of themes) does not look like it's possible, although Canonical did implement that with some hacks on top of GTK theme format for Ubuntu 10.04.

I'd be glad to be corrected on the above (grim) outlook or to hear other suggestions for solving the "Apps inconsistent with the DE" problem.

"I imagine such themes will profilerate wildly if you ditch the configurability,
because to test a theme on a different button layout the designer would have to
install another freaking DE instead of simply changing a setting."

Without configurability, there is no such thing as "testing a theme on a different button layout". There is only "testing a theme on a different platform, which happens, among other differences, to have a different button layout". If that's the goal to begin with, then having to install such platform seems like a reasonable requirement to be sure about it, specially because I honestly doubt that this is the only possible issue that can arise when you switch platforms.

And yes, designers probably wouldn't do that. And that's fine. Because releasing a theme that is specific to a platform is perfectly reasonable and expected. I don't think Dan tests eGTK on OSX.

With configurability, on the other hand, even designers wanting to support a single platform are supposed to worry about multiple button configurations, because this is something any user can change at any time.

You said it yourself: the issue here is "applications using GtkHeaderBar do not follow the button layout convention of the DE they run in". Proposing that the *USER* should be allowed to change the layout at any time, something inevitable when using GSettings, goes completely beyond the scope of such issue.

Whatever the solution is, the user shouldn't be able to access it. I stand that this is conceptually wrong.

Themes can now move the close button to the other side.