Things like color affect symbolic icons, but not colored icons, while
other css properties like -gtk-icon-effect affect colored icons, but not
symbolic ones.
If the theme has rounded corners for fullscreen, we don't tell the
window manager that we are now fully opaque, which then makes things
less efficient than they should be.
https://bugzilla.gnome.org//show_bug.cgi?id=761571
When we don't get a baseline passed in, we want to basically
center the children inside the allocation. There was an attempt
in the code to do 'internal baseline alignment', but it had the
side effect of moving the contents to the top when we don't get
a baseline passed in. Remove it for now, this needs some more
infrastructure to do properly.
https://bugzilla.gnome.org/show_bug.cgi?id=761363
We had some odd special-casing for the lowest and highest offset
that did not quite work. The new rule is simple: If the value
is between offset n-1 and n, it gets the style for offset n.
https://bugzilla.gnome.org/show_bug.cgi?id=761416
Don't allow syntax like
at top left circle
but follow the spec about requiring the at <position> right before the
comma.
This is porbably because
circle at 10px 10px
could be interpreted as
circle 10px at 10px
with the now disallowed syntax, too.
Test included.
Don't hardcode 96 for dpi, but instead use the value of the -gtk-dpi
property (that mirrors the GdkScreen's dpi if it wasn't set explicitly).
This makes these values scale when the large font setting in
control-center is enabled.
During the gadget conversion, the drawing of discrete levelbars
was unintentionally changed to draw a wide trough but narrow
blocks, which does not look great. So go back to the previous
way of drawing things.
https://bugzilla.gnome.org/show_bug.cgi?id=761428
Now selecting a widget by class name no longer works.
This is probably most relevant for users outside of GTK that want to
style their own widgets. Those widgets should now either add their own
style classes (if they want to adjust existing CSS) or use
gtk_widget_class_set_css_name() themselves (if they want to get rid of
all "upstream" styling).
And reset the grab_location in the ::released handler of the multipress
gesture.
Previously, when leaving fine-tune mode, the ::released handler of the
multipress gesture would call stop_scrolling, which calls
range_grab_remove and resets the grab_location. The ::drag-end handler
is executed after that, and only unsets priv->in_drag if the
grab_location is MOUSE_OUTSIDE, which it never was, since the ::released
handler already reset it. This lead to priv->in_drag being set even
though no dragging was in progress anymore, which e.g. made shift
pressed after leaving the fine-tune mode entering it again.
https://bugzilla.gnome.org/show_bug.cgi?id=761402
Calling _gtk_file_consider_as_remote() with a NULL argument
results in warnings being thrown.
Note that query->priv->location being NULL is a state that does
not seem to be invalid by itself.
This could happen if you do search-as-you-type in a filechooser,
which has a filter that does not match anything *and* the current
"place" selected is "Recent".
https://bugzilla.gnome.org/show_bug.cgi?id=761552
Instead of
/org/gtk/libgtk/theme/$THEME-$VARIANT.css
look at
/org/gtk/libgtk/theme/$THEME/gtk-$VARIANT.css
and that way mirror the directory layout of real themes.
