Sorry, first sentence should say: In GNOME 3.12, maximise and minimize buttons are available in the new header
bars that are present in some applications such as Nautilus.

Yes, that's a known problem. The problem is basically that the preference overrides in gnome-shell won't work for CSD decorations. Part of the solution would probably be in dconf/gio, but assigning to gtk+ for now which does the decorations in this case.

Florian, when I asked Ryan about desktop-dependend defaults, he didn't seem to have any concrete plans. Can we work out another solution ?

I don't think GTK+ will be involved here, either way. We provide a gtksetting/xsetting; it is up to the environment to make it have the right value...

(In reply to comment #3)
> Florian, when I asked Ryan about desktop-dependend defaults, he didn't seem to
> have any concrete plans. Can we work out another solution ?

Yeah. I think we can make this quite straight-forward actually, I'll attach a patch in a bit.

Created attachment 277190 [details] [review]
prefs: Sync button-layout setting with GSD's XSettings plugin

GTK+'s client-side decorations follow an XSetting to determine
which standard window buttons to show, similar to our own
button-layout setting in org.gnome.desktop.wm.preferences.
Keeping both mechanisms completely separate obviously means we
can end up with unwanted inconsistency, so we should link them.

Off-hand we have the following options:
 (1) Stop using our own setting and switch to XSettings instead
     (via GtkSettings:gtk-decoration-layout); this would fix
     the inconsistency, but break different defaults for normal
     and classic session
 (2) Sync our setting to gnome-settings-daemon's xsettings plugin's
     override key; this breaks the GSD key as a user setting,
     which might be undesirable for non-GNOME users of GSD
 (3) Invent yet-another-private-protocol between mutter/gnome-shell
     and gnome-settings-daemon for getting the default XSettings
     value from the WM before applying the override key; no
     downside apart from the added complexity as far as I can see

Provided that (2) works just fine for GNOME, let's go with that
for now - we can always reconsider (3) when third parties run
into actual problems with this.

Two things I don't like about this approach. First, Ryan doesn't like system components calling g_settings_set_* on system startup, which we would do whenever you switch to Classic, or back to Normal, if I understand it correctly.

Second, XSettings won't exist on Wayland. What do we do there?

I feel like with the new profiles stuff Ryan is working on for dconf, we should be able to have different defaults for the different sessions in a more natural way than our current overrides system.

(In reply to comment #6)
> I feel like with the new profiles stuff Ryan is working on for dconf, we should
> be able to have different defaults for the different sessions in a more natural
> way than our current overrides system.

Quoting comment #3:
"when I asked Ryan about desktop-dependend defaults, he didn't seem to
have any concrete plans"

So yes, I'm all for replacing our overrides system with session-dependent defaults once we get them, but it doesn't look like that's in the near future just yet ...

(In reply to comment #7)
> Quoting comment #3:
> "when I asked Ryan about desktop-dependend defaults, he didn't seem to
> have any concrete plans"
> 
> So yes, I'm all for replacing our overrides system with session-dependent
> defaults once we get them, but it doesn't look like that's in the near future
> just yet ...

I've talked with Ryan myself now, and while there are still a lot of unshaven yaks, work is underway.

So I'd say we can add code to both gnome-settings-daemon (X) and gtk+ (wayland) to
  (1) use the button-layout setting in org.gnome.desktop.wm.preferences to set
      the default gtk_decoration_layout
  (2) swap out the schema with org.gnome.shell.extensions.classic-overrides
      when XDG_CURRENT_DESKTOP indicates a classic session

(2) is pretty ugly, but acceptable as a temporary workaround in my opinion - it would be reverted as soon as we get proper XDG_CURRENT_DESKTOP-dependent defaults.

Created attachment 277949 [details] [review]
xsettings: Set Gtk/DecorationLayout from wm preferences

GTK+'s client-side decorations follow an XSetting to determine
which standard window buttons to show, similar to mutter's
button-layout setting in org.gnome.desktop.wm.preferences.
Keeping both mechanisms completely separate obviously means we
can end up with unwanted inconsistency, so use the GSetting
to back the XSetting on GNOME, just like we already do for
other settings (though it's a bit more involved, as the
possible values differ between mutter and GTK+).

Created attachment 277950 [details] [review]
xsettings: Explicitly handle classic mode for now

There are plans to add session-dependent defaults to GSettings
(based on the newly standardized XDG_CURRENT_DESKTOP); until
then, the WM uses a different schema for its button-layout
setting in classic mode. So for the time being, do the same
and pick the alternative schema when XDG_CURRENT_DESKTOP
indicates that we are in a classic session.
(It's not pretty, but hopefully won't be with us for too long ...)

Review of attachment 277949 [details] [review]:

Rest looks fine.

::: plugins/xsettings/Makefile.am
@@ +28,3 @@
 	$(AM_CPPFLAGS)
 
+noinst_PROGRAMS += test-wm-button-layout-translations

I'd rather you made a separate test-wm-button-layout-translations.c

Review of attachment 277950 [details] [review]:

Looks good.

Attachment 277949 [details] pushed as dc5619f - xsettings: Set Gtk/DecorationLayout from wm preferences
Attachment 277950 [details] pushed as 1eb4544 - xsettings: Explicitly handle classic mode for now

Moved test to a separate file (the main idea here was that wm-button-layout-translation.[ch] are shared with gdk's wayland backend, and that keeping the number copy-pasted files down is a good thing - but then I didn't even bother to enable the test on the gtk side anyway ...)