| zzag | |
| ngraham |
| Breeze | |
| VDG |
Use and generate correct colours from the window manager palette rather
than the window palette in the headerbar.
BUG: 403426
This works beautifully on wayland, on X11 kwin doesn't send
NET_WM_STATE_FOCUSSED and GTK doesn't correctly handle WMs that don't support it.
Might be worth not committing this till then.
Ran gtk3-demo which requests CSDs
| Automatic diff as part of commit; lint not applicable. |
| Automatic diff as part of commit; unit tests not applicable. |
What's the reason for removing the linear gradient?
In the old code it was a gradient between $WindowBackgroundNormal and $WindowBackgroundNormal which obviously did nothing so I removed it.
But I think you're right that breeze technically should change slightly.
On X11, gtk isn't selecting the backdrop class. Probably because kwin doesn't support one of their new activation flags which would be a GTK bug for not following their fallback correctly.
If this is the case, then it's a bit awkward because GTK doesn't follow spec they wrote.
Might be worth not committing this till then.
Are GTK developers aware of this problem?
But I think you're right that breeze technically should change slightly.
Given that Breeze kdecoration settings are not synchronized with GTK theme, I think it's fine to have solid background color (though it would be great to match defaults).
| src/gtk320/widgets/_headerbar.scss | ||
|---|---|---|
| 16–17 | This is probably redundant. | |
| src/gtk320/widgets/_headerbar.scss | ||
|---|---|---|
| 16–17 | Argh, please ignore this comment. It looks like background-image: none, background-color: ..., is used throughout the theme. | |
Are GTK developers aware of this problem?
There's an old bug report, I've just added some info to it.
https://gitlab.gnome.org/GNOME/gtk/issues/499
I'm not 100% against adding the focus state in kwin.
