Give a self-decorating app srdwm's own titlebar look, not just its buttons

Reported live, after the button work landed: "I still don't see our custom
overriding decorations, ie on nemo."

Measured what actually happens, in a nested compositor with a deliberately
garish diagnostic rule: srdwm's stylesheet does reach Nemo's window buttons
- the close button took the diagnostic colour. What it did not reach was
the bar those buttons sit in, so Nemo kept its own header bar in its own
GTK theme's colours next to srdwm's titlebars everywhere else. Two
titlebars, two looks, which is what "not our decorations" was describing.

The stylesheet now also carries srdwm's own titlebar background, text
colour, height and title alignment. A client-side-decorated application
draws its header itself and no protocol reaches that - GTK never
negotiates decoration at all - but its stylesheet does, so the two can at
least be told to look the same.

Verified on screen: with the compositor told one colour and the stylesheet
generated for another, Nemo's own header bar sampled at exactly the
stylesheet's colour. In a real session both come from the same theme value,
so they match.

Deliberately conservative about size. A GNOME app's header bar is also its
whole toolbar - search, menus, view switches - so `min-height` can only
raise the floor to srdwm's own height, never cap it, and no padding,
margin, font-size or spacing is set at all. A test asserts the header bar
rule sets none of those, so a later edit cannot quietly start squeezing
other applications' controls.

Also measured, and worth writing down because it bounds what is possible:
Nemo shows one close button and nothing adds minimize or maximize to it --
not `gtk-decoration-layout` in settings.ini, not the gsettings button-layout
the portal serves, and GTK_CSD=0 does not remove its header bar either. A
client that builds its own header decides what goes in it. Style is
reachable; contents are not.

0 files changed, 0 insertions, 0 deletions