In case the X11 backend is not enabled, we still need to include the
pangofc-fontmap.h header file, as we use the Pango/FontConfig API in
both the X11 and Wayland case.
https://bugzilla.gnome.org/show_bug.cgi?id=751625
Marking these as "Since: 3.14.1" may be more accurate, but
it causes gtk-doc to not put these symbols in any versioned
index at all (it generates an unused index for 3.14.1). So,
lets lie a little, and say these symbols were added in 3.14.
The button and menu item icons settings are deprecated; application
developers should control whether or not a widget should show an icon,
using the existing API.
https://bugzilla.gnome.org/show_bug.cgi?id=750718
Load themed cursors from the same places they are loaded on freedesktop systems,
but use W32 API functions to do so (works for .cur/.ani cursors instead of X
cursors).
Refactor the code for cursor handling. Prefer loading cursors by name.
Do not load actual cursors when loading the theme. Find the files and remember
the arguments/calls for loading them instead. Keeping HCURSOR instance in the
hashmap would result in multiple GdkCursors using the same HCURSOR. Given that
we use DestroyCursor() to off them, this would cause problems (at the very
least - DestroyCursor() would fail).
Store GdkCursor instances in a cache. Update cached cursors when theme changes.
Recognize "system" theme as a special (and default) case. When it is set,
prefer system cursors and fall back to Adwaita cursors and (as a last resort)
built-in X cursors. Otherwise prefer theme cursors and fall back to system and
X cursors.
Force GTK to use "left_ptr" cursor when no cursor is set. Using NULL makes
it use the system default "arrow", which is not the intended behaviour when
a non-system theme is selected.
Ignore cursor size setting and query the OS for the required cursor size, as
Windows (almost) does not allow setting cursors of arbitrary size.
https://bugzilla.gnome.org/show_bug.cgi?id=749287
This guarantees we only create 1 extra style cascade in total for hidpi
and not one per style context.
Style cascades are now nested like this:
GtkSettings root cascade (scale == 1)
|
+-- GtkSettings per scale cascade (for any scale, no custom providers)
|
+-- GtkStyleContext custom cascade (for any scale, custom providers)
This requires a bunch of care when changing cascade-related properties
inside GtkStyleContext, so that it ends up with a properly setup
cascade, but I think I got those cases right.
The only thing we don't do yet is reverting to a GtkSettings cascade
when the last custom provider is removed from a custom cascade.
Arrange things so that gtk-xdg-hinting==-1 and gtk-xfg-antialias==-1
end up as CAIRO_HINT_STYLE_DEFAULT and CAIRO_ANTIALIAS_DEFAULT in the
cairo font options.
This will not change anything on Linux desktops where xsettings will
always provide values different from -1. But on other platforms, we
can benefit from getting the platform-specific defaults in cairo.
Based on the first patch in:
https://bugzilla.gnome.org/show_bug.cgi?id=735316
These match the GSettings that mutter/metacity/gnome-shell have
for this. We change the default for the middle-click action to
none, since lower is just a terrible default.
We're slightly bending the rules here, since we're adding new
settings after .0, but a) it is just barely after .0, and b) settings
are not really application API.
https://bugzilla.gnome.org/show_bug.cgi?id=729782
Settings have a little more metadata than plain properties. They
can come from different sources. Make this information available
so we can show it in the inspector.
https://bugzilla.gnome.org/show_bug.cgi?id=736971
gdk_x11_display_set_window_scale() affects the interpretation of the
Xft/DPI XSETTING - it is substituted inside GDK with the value of
Gdk/UnscaledDPI xsetting. However, this change is not propagated to
GTK+ and from GTK+ back to gdk_screen_set_resolution() until the
main loop is run.
Fix this by handling the screen resolution directly in gdk/x11.
This requires duplication of code between GDK and GTK+ since we still
have to handle DPI in GTK+ in the case that GdkSettings:gtk-xft-dpi
is set by the application.
https://bugzilla.gnome.org/show_bug.cgi?id=733076
We decided in f8412eca34 that
we still need to react to these for a11y reasons, but left
the (then) harmless property deprecation in place. Now, the
deprecation causes runtime warnings for merely reading the
property, so drop it.
https://bugzilla.gnome.org/show_bug.cgi?id=732667
The icontheme lookup code has a special-case that prefers builtin icons
if the theme name is "hicolor". This is problematic for our reftests,
which run in a barebones environment with not settings.
