Commit 4ee02725b4 made the :hover apply to
the title node, not the arrow node, but the selectors it added were not
caught by the recent commits fixing the specificity of title > arrow.
Putting a combobox in an expander was causing the combo arrow
to go sideways. Increase the specificity with which we address
the expander arrow to avoid that.
The HighContrast theme was not parsing anymore, due to
leftover widget style properties, and some missed cleanups,
like -gtk-icon-effect. Also update for the new focus handling,
and make checks and radios sharp again.
Instead of looking at the icon size, look at the CSS value for
-gtk-icon-size. Set style classes depending on icon size instead.
Trivially change Adwaita and HighContrast to report the same values as
before.
• Remove the box-shadow at the top when the entry is in the foreground
• Bump precedence so that :disabled entries do not have .flat overridden
• Also add :backdrop to stop HCInverse getting a lighter BG in :backdrop
https://bugzilla.gnome.org/show_bug.cgi?id=789733
It was selecting paned separator, which means any separator at any level
of descent within a paned, including the toplevel container in GEdit.
We need to be more specific and only select the relevant separator that
is the direct child of the paned. This is what Adwaita does.
https://bugzilla.gnome.org/show_bug.cgi?id=788573
The border and icon highlight are useful feedback that was defeated by
CSS precedence. It worked for .titlebuttons due to their implementation,
but the same was not true for custom .flat buttons. This makes it so.
https://bugzilla.gnome.org/show_bug.cgi?id=788580
When the window was backdropped, they suddenly regained their border.
This was clearly not intentional or of any practical use to anyone.
Shuffle around some selectors so that the backdrop ones do not override
the flat ones and make the borders magically reappear when backdropped.
Note that, whereas standard titlebuttons get the border on :hover, other
.flat buttons in the headerbar do not. That should probably be fixed too
https://bugzilla.gnome.org/show_bug.cgi?id=788580
They were hard-coded to a transparent black, but that is our bg colour
in HC Inverse, so windows stacked on top of each other or a dark
background blended together into a mush.
Fix this by making the $_wm_border* colours relative to the fg colour,
so that HighContrastInverse gets borders that are transparentised white.
https://bugzilla.gnome.org/show_bug.cgi?id=788575
A missing decoration selector meant that we got a solid black background
behind the rounded corners of the dialog.
Copy the equivalent code from Adwaita, including nicely rounding the
focus outline too (& sorry, but this needs more newlines to be readable)
There were various problems, like only selecting on .tooltip and not the
widget node tooltip, not being specific enough for tooltip.csd, etc. So,
specific theming was absent, and default popup window styles got applied
This commit copies in the better working tooltip CSS from Adwaita, but
applies a couple of changes to make it work better in the HC themes:
• Reduce the transparency of the tooltip, so we achieve higher contrast
• Drop the black text-shadow, as it is not useful on this more black bg
Note: we may then need to re-add some of this to the .tooltip class. But
it is unclear what needs done there. While Adwaita is not doing it, we
are better not to confuse by keeping it in HC only; we should try to be
as close as possible, to make it easier for HC to keep up with Adwaita.
https://bugzilla.gnome.org/show_bug.cgi?id=769879
We need
.window-classes decoration
but within the decoration parent selector, we were doing
&.window-classes, which gave us
decoration.window classes
We need to fix this by selecting on .window-classes &
https://bugzilla.gnome.org/show_bug.cgi?id=788496
The last touch on this patch series is making GtkWindow able to
selectively adjust various UI details based on the different
tiled edges. The main driver here is that we don't want to show
shadows on edges that are constrained.
This patch adds the necessary code to do that, while still
maintaining compatibility with the old ways.
https://bugzilla.gnome.org/show_bug.cgi?id=783669
The focus outline disappeared as the colour of the swatch got close to
the normal focus outline colour, which is alpha(currentColor, 0.3).
Fix by making the outline an alpha’d version of the tick colour, but
more opaque than normal outlines. 0.6 seems good enough; feel free to
improve it, but at least this ensures the outline can’t vanish anymore.
HighContrast achieves this already because it applies the color property
to the main node, not the overlay. Doing that means the outline is fully
opaque, which is fine for HC obviously but was excessive for Adwaita.
https://bugzilla.gnome.org/show_bug.cgi?id=787757
It used $text_color unconditionally, but in :dark, text is white, so we
overlaid a white tick on any light colours, all the way to white itself.
Using these named colours doesn’t make practical or semantic sense.
Instead, use white/black over dark/light swatches, as in HC, so all
variant–swatch combos work. Light looks the same, & :dark works now.
For backdrop, use alpha 0.5, unlike 0.7 in HC, as that seemed excessive
& different from the current effect. 0.5 is almost identical to how
$backdrop_fg_colour is a 50% mix of $fg_color, & matches backdrop text.
https://bugzilla.gnome.org/show_bug.cgi?id=787531
Use opacity to differentiate unselected/hovered/selected buttons. It had
assumed bg < border < fg colours, which may be false, as in Adwaita:dark
This also means we do not need to special-case for the backdrop state.
https://bugzilla.gnome.org/show_bug.cgi?id=786956
in a specific case, which was applying .slider as a class on the parent
switch, instead of correctly selecting on its child node named slider.
This makes the border on the outside of a switch in a selected listbox
row look better in the light variant. Since the code was never removed,
it was clearly meant to work, and making it work is a clear improvement.
Themes should not enforce min sizes on blocks in continuous mode; in
this case, the filled block should be as large as it needs to be to
reflect the current value, and no larger or smaller than that. So, the
fact that the minimal size was selected on just levelbar block is wrong:
we should also require the levelbar.discrete class to apply min sizes.
The widget should enforce whatever correct minimum size results from the
above fix, by reapplying commit 78b4885fe8
Except: we should not allocate/draw the filled block if the value is 0,
as in this case, the LevelBar should be empty, not have a min-size fill.
This partially reverts commit 96062ffeae,
as it makes sense to set min sizes for discrete blocks, so keep that in.
https://bugzilla.gnome.org/show_bug.cgi?id=783649
