Simplify the styling of sidebar separators by not setting their borders
and margins rather than trying to drop it afterward, which was actually
not working anyway.
Make the selector less greedy to not remove the background on
non-titlebar headerbars contained in non-headerbar titlebars and only to
the ones contained in headerbar titlebars. This avoid issues in some
applications.
Also make dropping the background more agressive to actually remove it.
This is needed to work around headerbar sliding animation issues without
refactoring Adwaita's support of titlebars and headerbars as it may
break applications.
https://gitlab.gnome.org/GNOME/gtk/issues/1264
Let separators be declared as sidebars to have the same style as those
drawn by GtkStackSidebar. This also let them handle the selection-mode
class, whether they are assigned it or they descend from something in
selection mode.
This is convenient when building a custom sidebar using a GtkSeparator
and to extend a sidebar to the title bar.
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
It has been extremely broken since the move to CSS gadgets/nodes, so
clearly no one is depending on it; nor does anyone seem to want to
resurrect it, and writing a Raleigh-inspired theme from scratch would be
faster if they did. So let's drop the dead weight from the build and lib
Now that we don't have Raleigh, the defaultvalue test has to be changed
to set Adwaita before checking the default values of style properties -
some of which Adwaita overrides in its CSS, meaning those would fail.
Not that it passed before anyway! But it does now after my other commit.
Note that I leave the last reference in gtk-zip.sh.in alone since that
hasn't been touched in 8 years and probably has plenty other problems...
Close https://gitlab.gnome.org/GNOME/gtk/issues/1187
border-spacing was not backported (yet?). If it won't be, then a
suitable replacement is needed. Until then, avoid the runtime error that
can result from using a nonexistent property in our theme.
https://gitlab.gnome.org/GNOME/gtk/issues/1166
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
Match "box" instead of "*", as already done for the search bar GTK4 and
for the action box in GTK3. Also clarify which widget property is
causing the margin which needs to be undone.
Includes applications like GNOME Software and GNOME Documents. The
search bar is a composite widget with a revealer inside it, and when the
content of the revealer is hidden, the border lingers. Changed the CSS
to add style to the content of the revealer instead of the search bar
widget itself.
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.
• 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
We moved from the Ruby compiler to sassc in
commit 67953e9cfb, so this copies across
the updated info about building from GTK+ 4.
Also, explain the purpose of parse-sass.sh, since while that is not
mentioned in GTK+ 4 – and perhaps does not need to be, thanks to Meson –
we are still on Autotools here, and rebuilding the entirety of GTK+ 3 if
you only edited the CSS is a lot of waiting for no good reason.
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)
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
