Another selector forces round corners for headerbars in a stack, and it
has higher priority than the selector covering the non-stack case from
commit 796f9b5bfb. Totem’s MainToolbar
happens to be in a stack, and we should maintain symmetry here anyway.
So, as window classes .maximized and .tiled are excluded from this other
selector, the newly handled .fullscreen case must be excluded here also.
https://bugzilla.gnome.org/show_bug.cgi?id=770513
Totem uses a fullscreen window with a headerbar at the top, and without
this change, that headerbar has rounded corners, which look different
from a maximised window and let video content show through beneath.
https://bugzilla.gnome.org/show_bug.cgi?id=770513
The :last-child selector supposed to reset the border was
overridden by the :hover selector. This is fixed by moving the
:last-child selector after the overriding one.
Thanks to Sebastian Keller for spotting.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=779078.
Instead of
-gtk-icon-effect: dim;
-gtk-icon-effect: hilight;
we now use
-gtk-icon-filter: opacity(0.5);
-gtk-icon-filter: brightness(1.2);
respectively.
It does weird clipping that
(a) nobody likes
(b) is hard to support in the new rendering world.
So we take the easy way out.
The actual frame is now drawn by the frame node around the label.
the darker bottom border used on buttons looks bad on circular ones
so now a gradient clipped on the border-box and a transparent
border is used in that partcular case.
See https://bugzilla.gnome.org/show_bug.cgi?id=771205 for details.
$button_fill contains the background-image property value of
buttons, having it readable outside the drawing mixin allows, for
example, stacking background images in an easier way.
to hilight drop target there is a wildcard selector which turns
the border and shadow to green, this clearly shouldn't happen when
the whole window is a drop target.
- while we don't use steppers anymore, for some reason they are still
defined in the theme and if you sacrifice a chicken and jump on one
leg at full moon, you can enable them.
https://bugzilla.gnome.org/show_bug.cgi?id=769498
...or warning style class applied.
This particular style bit wasn't converted to the saner 3.20 way
so `entry:selected` used in place of `entry selection`.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=768025
we used to style infobars by using the .info, .question, .warning
and .error selectors directly, which used to be ok when we had just
styleclasses all over the place, now it needs to be more specific
or it interferes with everything with those styleclasses applied
like entries.
