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.
There's nothing better we can do for this case, now that we always
redirect drawing to a temporary pixmap. Maybe since this is already
X11-specific code, we should just do everything with Xlib directly.
gtk_widget_set_double_buffered is now deprecated, and we don't support
non-double-buffered widgets. This means that under normal circumstances,
paints are never outside of a begin_paint / end_paint sequence, which
natively-double-buffered backends like Wayland can't possibly support.
Add /org/gtk/libgtk/icons as a resource path, and ensure
that we always parse an index.theme file for hicolor which
makes the builtin icons available as part of the hicolor theme.
We add a new API, gtk_icon_theme_add_resource_path, which
can be used to add resource path as a base location for
icon theme content, similar to gtk_icon_theme_append_search_path.
We're going to require a complete icon theme, and we have
a test that checks for all the icons we use, so there is
no need to include all these fallback icons.
Regions are done in a very non-css way. They don't fit the DOM in that
they don't integrate into the CSS tree and they have very weird matching
behavior in selectors.
So I'm deprecating them now. GtkNotebook and GtkTreeview will continue
to use them and as long as they do, we can't remove the code for it.
But once those are ported it might be safe to remove the code as it will
clean up lots of places in the code by quite a bit.
The rubberband rendering code was assuming that we just have
a 1-pixel border and the rest of the rubberband is uniform.
That is not a safe assumption to make with css-styled
rubberbands, so remove it.
The rubberband rendering code was assuming that we just have
a 1-pixel border and the rest of the rubberband is uniform.
That is not a safe assumption to make with css-styled
rubberbands, so remove it.
Paradoxically, we were loading svgs at the nominal size when
FORCE_SIZE is specified, while scaling them exactly when it
isn't.
../build/win32/vs10/gtk.vcxproj
