We shouldn't give the icons here the same fg colour as the bg... which
makes them disappear and the buttons look like meaningless flat squares.
Fix by just using the same colour the same as foreground disabled. Note:
insensitive_fg_color is more prominent than !disabled, so clearly wrong.
Expanders used to be 16px high. With the move from the gtk2 rendering
to gtk3 rendering they shrunk to 12px, making them hard to see, because
it's now the icon which is 16px high and the icon contains transparent
borders.
This makes the HighContrast theme use 24px icons instead, to restore
16px expanders. This may expander some containers a bit.
Closes#1046
Selected rows in tree views in HighContrast have a background colour the
same or nearly as the normal text colour, so we cannot let entries in
such rows have transparent backgrounds, or the text inside the entry
becomes nearly or totally impossible to see.
Dodge this by giving entry.flat inside treeview and with :focus the
$base_color, which is different from the text & so lets that be seen.
https://gitlab.gnome.org/GNOME/gtk/merge_requests/125
.linked assumes the container is a GtkBox, which is documented as never
flipping children in RTL, so :first-child is always the left child, etc.
GtkBox does that by reordering its CSS nodes when the direction changes.
But most widgets don’t do that, so :first|last-child are 1st/last ADDED
and swap sides in RTL. GtkPathBar is so, and ignoring that in our themes
meant that in RTL, its left/right buttons got each other’s borders. Yuk!
This patch adds the groundwork for supporting widgets like that, via the
%linked_flippable placeholder, and applies that to override buttons in
filechooser .path-bar.linked > button
so that the correct borders get applied to those buttons when using RTL.
Note that I select only PathBars within a FileChooser because we also
have NautilusPathBar, which also uses widget.path-bar – but *does* flip
its nodes for RTL already, so letting that get affected broke it again!
https://bugzilla.gnome.org/show_bug.cgi?id=772817
If GtkExpander:sensitive was FALSE, the arrow still got the normal fg
colour, which made it look clickable, in contrast to the adjacent label.
Fix this by adding selectors to catch the applicable :disabled states.
Note: Needing these may indicate an oops in generic styles elsewhere,
but I couldn’t see any, so let’s just get it looking right for now.
https://gitlab.gnome.org/GNOME/gtk/issues/146
• 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
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)
https://bugzilla.gnome.org/show_bug.cgi?id=788574
by migrating the relevant code from Adwaita, to dodge unwanted doubling
up of the bottom border and such.
It also hopefully still encompasses whatever commit
b4371728de was trying to do; certainly, it
retains the resolution of the main bug/patch that one was attached with.
https://bugzilla.gnome.org/show_bug.cgi?id=769877
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
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.
https://bugzilla.gnome.org/show_bug.cgi?id=783649
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
Changing code to agree with docs, which said frame.flat, was backwards.
Mea culpa. Theme authors ran with the actual behaviour, not the docs. As
stability is more important, let’s go back to frame > border.flat, and
fix the docs to reflect what the code does and how to set .flat in code.
N.B. This retains the change in HighContrast of "frame border" to "frame
> border". Not using the direct child selector contradicted Adwaita &
could conceivably have unwanted results on nested nodes named border.
https://bugzilla.gnome.org/show_bug.cgi?id=778905
The docs say that this class should be put on the frame node, and that’s
all we can do from C code, but the CSS was selecting on the border node.
The result was that adding .flat did not disable the border as expected.
https://bugzilla.gnome.org/show_bug.cgi?id=778905
- 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
