Since we are really only interested in the center point of the
slider allocation, the pre-computed slider geometry is perfectly
fine, just use it always. This avoids the complication with
gadget visibility.
The slider gadget may be turned invisible as side-effect of
gtk_range_calc_slider(). If that happens,
gtk_css_gadget_get_content_allocation() returns { 0, 0, 0, 0},
which leads us to calculate a negative allocation for the highlight
node. Avoid this, by just reusing our already calculated slider
allocation in this case (it is not technically the same as the
content, allocation, but the difference hardly matter here.
https://bugzilla.gnome.org/show_bug.cgi?id=764022
These functions are supposed to return the numbers of consecutive
1 bits in each components mask as precision. However, due to a
copy-paste mistake when this code was moved around in
commit 70d689cddd, the precision
was always reported as zero. This affects only a few applications
that directly set window background on X11 windows, such as emacs.
https://bugzilla.gnome.org/show_bug.cgi?id=764210
Some other widget might have mapped and raised another child window of
the toplevel in the meantime, causing the popover window to be covered.
Raise the popover window to avoid the issue.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=763627
gtk+ currently depends on the scaling factor and the cairo device scale
of both the backend surfaces and image surfaces to be equal.
Until now we didn't apply a cairo device scale at all and depended on the
automatic scaling of CGContexts. This works when drawing with cairo but
fails in case of image surfaces, which get requested at a too small size.
To make the quartz backend behave more like the X11 one, set the cairo device
scale on the surface in gdk_quartz_ref_cairo_surface(). As this conflicts
with the default scaling done by CGContext (we would get double scaling)
undo the CGContext scaling using CGContextScaleCTM().
This patch is based on the following patches by Brion Vibber:
https://bugzilla.gnome.org/show_bug.cgi?id=740199#c4https://bugs.freedesktop.org/show_bug.cgi?id=69796#c4https://bugzilla.gnome.org/show_bug.cgi?id=763779
When loading a per-theme settings.ini file, look for it in
the same directory where we found the gtk.css file for the
theme. Previously, we were always looking in
$prefix/share/themes/THEME/gtk-3.0/, even if the css was
loaded from somewhere else.
https://bugzilla.gnome.org/show_bug.cgi?id=641354
With this change, we now look in
$XDG_DATA_HOME/themes/THEME/gtk-3.x
$HOME/.themes/THEME/gtk-3.x
$XDG_DATA_DIRS/themes/THEME/gtk-3.x
GTK_DATA_PREFIX/themes/THEME/gtk-3.x
https://bugzilla.gnome.org/show_bug.cgi?id=641354
