.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
This way, we avoid a 1px border at the bottom of the actual searchbar
widget and move it instead to the child of a GtkRevealer. Since we can
now use widgets with 0px height, we finally get rid of the 1px border
that was drawn even if the searchbar child was hidden.
Avoid the ugly priv->tool_box==NULL check in ::add (and ::remove) by
just not using template xml for this small class. Also, make sure the
GtkBin child is properly set and implement remove to also properly
remove it. Remove the manual widget margins and add some CSS for it.
Also switch to simply using a GtkCenterBox.
So the slider does not overlap the value label. Since the value label is
allocated at the widget edge in gtk3, the correct fix here would
probably be to remove the 12px padding we apply to the entire scale and
instead apply it only to the trough.
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 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
menu margins have been added has a hack to mitigate bug:
https://bugzilla.gnome.org/show_bug.cgi?id=591258 with gtk+4 this
doesn't work anymore on gtk+4, the margin should probably be moved
to the parent window node, but it's not selectable, commenting out
for now.
Remove the special case in gtkwidget.c where we didn't draw any css
background/border for popovers. Instead, rely on themes to not style the
popover node and add a contents gizmo that gets the actual css styling.
We then requeste enough space for the popover to draw both the contents
and the arrow on the side.
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.
