Prevent a segfault in unknown circumstances, and break the ignore
deprecations wrapper out from the if statement so that we don't
cover too much ground by accident.
This reverts commit b875572f2a.
Apps like Abiword, gnumeric and gnome-chess, and toolkits like
ClutterGTK were all using this for various purposes, and this made them
break. Bring back this feature for now.
It still won't work under Wayland.
Apps had quite a bit of difficulty getting used to the new rules.
While we weren't expecting anything too deadly, it seemed that
gnumeric and Abiword both used gdk_cairo_create like this.
If a window both has an impl and its impl_window is of type offscreen,
that must mean that it is the offscreen window, and the impl window is
itself. We can reduce the indirection here and make it more clear.
This functionality is only exercised by gnome-shell, currently.
Therefore, forgetting to copy a field here means an instant
gnome-shell crash :-(. More tests needed.
Recent changes made it a breaking mistake to install symbolic icons
of the wrong size into a theme directory, or into the legacy unthemed
icon location.
Since this change affects many apps, do the extra work to keep these
icons working, but emit warnings, in the hope that this will lead to
cleaning up the mess over time.
The -gtk-icontheme() function not have any automatism for
symbolic or rtl variants built-in, instead, we expect the theme
to use selectors to provide the right icon for each situation.
The recent icon theme scaling changes make the code more
sensitive to mis-sized icons (e.g. application icons in
the app chooser). A single row whose size gets blown out
of proportion by a big icon is never wanted in a list.
We can avoid this situation by telling GtkIconHelper to
force-scale the pixbuf to the requested size.
When force_scale_pixbuf is set, the icon helper will scale the
icon to the requested size (either the pixel size, or the resolved
icon size), so we can just as well instruct the icon theme code
to do the scaling for us.
Reuse the scale information that we have from loading icons
normally, when loading a symbolic icon, so that we apply the
same size constraints.
This commit assumes that svgs have the nominal size of the
directory they are in, which will be true for all current
symbolic icons.
Previously, we were taking thresholds and min/max sizes into
account when choosing the best theme dir, but when it came
to loading the icon, we always scaled icons from scalable
directories all the way, ignoring the min/max size limits.
This commit changes things around so that we now load icons
in Threshold directories at their nominal size, and scale
icons in Scalable directories only up to the specified limits.
To override this and keep the previous behaviour of scaling
all the way to the desired size, use the GTK_ICON_THEME_FORCE_SIZE
flag.
Since the Win32 code never actually called InvalidateRgn or used the
Win32 update area at all, that meant the only thing that could possibly
invalidate the window was the Win32 window manager as part of scrolling
or resizing, which would also send it a WM_PAINT message.
But the WM_PAINT handling called BeginPaint / EndPaint, which clears the
update area completely! We also draw out-of-band, not directly when
handling WM_PAINT, so there's no way that the update area inside the
Win32 WM would match our local one.
There is no possible way that this queue_antiexpose implementation could
do anything. Remove it.
We removed the parameter from callers and from the implementation, but
not from the signature up top. I didn't notice because the branch I was
working on removed the signature entirely.
This code is only called with the current paint region as its argument.
Instead of having to copy it and do a no-op intersect against itself,
just use the current paint directly.
