They are no longer supported by sass and broken with libsass 3.6.3
(https://github.com/sass/libsass/issues/3033)
This removes them by replacing them with a placeholder selector. This at
least brings the resulting CSS size down a bit so gtk can be build
again.
`%button.flat.suggested-action` has been replaced by
`%selection_mode_button_flat`, which is a more appropriate selector for
`.selection-mode button.titlebutton`.
The CSS was generated with libsass 3.5.5.
Co-authored-by: Christoph Reiter <reiter.christoph@gmail.com>
See https://gitlab.gnome.org/GNOME/gtk/issues/2237
The expander icon is renamed from "arrow" to "expander".
The expander widget itself is renamed from "expander" to
"expander-widget" (Better ideas welcome).
This makes it possible to have an "expander" icon in more places then
the GtkExpander widget (in particular in tree lists) and not
confuse it with arrows.
Instead of re-styling the border and radius of the linked buttons
depending on the position (middle, first, last, or only child), just
remove the border and radius in a specific direction when the button is
`:not(:first-child)` and/or `:not(:last-child)`.
This properly handles the style of linked buttons in all positions
-- middle, first, last, and only child.
Fixes#1294
We don't want to render focus rectangles on everything. With
the way focus is propagated nowadays, the theme has to selectively
render focus on certain widgets.
At the same time, we always want to render focus for this
theme, so use the focus pseudoclass, not focus(visible).
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1815
The min size on the oriented axis used to come from style props with
default values in the source file, used if the theme did not provide a
min size in CSS. When the style props were removed, so was any notion of
a minimal size for proressbars' main axis, meaning that now progressbars
without expand or any other source of min size were just tiny specks.
The right place to do that was always the theme, so in our themes now,
fix that by copying the old default values for the style properties; see:
https://gitlab.gnome.org/GNOME/gtk/issues/1191#note_259393https://gitlab.gnome.org/GNOME/gtk/blob/gtk-3-24/gtk/gtkprogressbar.c#L92
The result should be the same in that (A) the min size is now what it is
in GTK+ 3 & (B) an app/user can override the theme exactly the same way.
Close https://gitlab.gnome.org/GNOME/gtk/issues/1192
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.
Close https://gitlab.gnome.org/GNOME/gtk/issues/146
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.
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
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
