Florian, can you take a look ? I'm not sure whats missing here, and don't have a mutter thats linkeds against gtk master atm.

(In reply to Mantas Mikulėnas from comment #0)
> (I'm guessing in 371f501?)

That guess is correct. The commit replaced the ".window-frame" class with the "decoration" CSS node name in the theme. As CSS nodes are internal to GTK+, this isn't something we can currently fix in mutter - we either need API to set the node name on a style context (without going through GtkWidget), or revert the theme changes in that commit.

But .window-frame was just as internal to gtk+. How is mutter depending on this implementation detail of GtkWindow ?

Because it's the API GTK+ gives us for drawing server-side decorations the same way GTK+ draws client-side decorations without being a GTK+ application. We build a hierarchy of GtkStyleContexts that matches the hierarchy in a GtkWindow with a headerbar and buttons, then use the gtk_render_* functions for drawing.

The only alternatives to that approach as far as I can see are:
 * go back to use a separate window manager theme and try to keep
   it in sync with GTK+ (the pre-3.16 situation, which sucked)
 * add public API to GTK+ that allows us to stop relying on implementation
   details, but that's likely to be useless to anyone but mutter

Neither of those sound very compelling to me ...

Please, don't give me back a window manager theme.

We've added gtk_widget_path_iter_set_object_name which should let mutter do what it needs to do.

The following fix has been pushed:
2750db2 theme: Set object-name on style contexts

Created attachment 314196 [details] [review]
theme: Set object-name on style contexts

The default theme started to use them in GTK+ commit 371f50, so
we need to update the style contexts to keep matching the style
of client-side decorations.