Gives the same background color to all separators descending from a
title bar than to its direct childrens.
This prevents separators which are in a titlebar but not direct children
from the widget with the titlebar style class from being almost
transparent and hence it prevent them from revealing the clear color of
the window's titlebar (black).
https://gitlab.gnome.org/GNOME/gtk/issues/1231
- Selection mode does not get the special devel styling.
- removed teh last-child() selector for it doesn't work anymore.
Better style all section of the headerbar than none. Proper fix pending.
https://source.puri.sm/Librem5/libhandy/issues/57
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.
Also drop setting the selection mode color for non-sidebar separators.
This is convenient when building a custom sidebar using a GtkSeparator
and to extend a sidebar to the title bar.
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
This step was missed before, again.
SASS 3.6 emits rgba(0, 0, 0, 0) instead of transparent, so it wants to
change those too, but that patch was only committed in March and isn't
being backported to the previous stable, so I don't know if others'
versions will do the same - so until it's shown that anyone else (A) is
regenerating CSS and (B) also has 3.6, I'm skipping those changes. See:
c287f312ac
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
.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
