At best, it's just an awkward event mask sitting there for a backend
that does not need it. At worst, this may result in motion events being
eaten away in the right set of circumstances.

Avoid the pointer motion hint mask, and rely on events being further
than hints.

Related: gimp!534 (comment 1526935)

They should be enclosed by $() not ${}.

The theme is considered deprecated in favor of symbolic icons from
the regular theme.

shouldInheritContentScale was introduced in 10.14.

[gtk3] [x11] Fix coordinate space of rect in gdk_x11_window_get_frame_extents when called on popups.

This is the same fix as !4820, but applied to the gtk 3 branch.

Fixes #4899

In case of an offscreen window find its onscreen embedder, and NULL
any GdkWindowImpl that's not quartz, checking all return values.

This replaces 16ded683, removing its unnecessary search_for_nearest
functions.

Any unchecked cast of a GdkWindowImpl to GdkWindowImplQuartz risks at
least getting an invalid member reference, not just the ones in
gdk_quartz_window_get_foo, and all calls to gdk_quartz_window_get_foo need
to be checked, not just Gtk's internal calls. The motivation was that
transient_for was getting set on a Gimp offscreen window and that caused a
crash in raise_transient.

Includes creating the CVPixelBuffer to supply the layer contents when
creating the cairo_image_surface, which reduces the number of them created
at the wrong scale.

To prevent leaking cairo surfaces while persisting the parts that
don't need to be redrawn.

This uses CVDisplayLink to drive the GdkFrameClock. A GdkWindow
can register a frame callback to thaw their frame clock as necessary
based on the next notification from CVDisplayLink.

CVDisplayLink notifies us on a high-priority thread. We use the same
NSEventas gdkeventloop-quartz.c to wakeup the main loop. This is done
so that we don’t pathologically wake up the select thread to then
continue notifying the main loop.

We use an embedded GList node in the GdkWindowImplQuartz so that we
can avoid allocating any lists or arrays for pending frame callbacks.
Compare this to the same design in GdkWindow for children.

We no longer use the autotools 'dist-hook' to generate the items that we
need to build introspection with the Visual Studio projects, so drop the
autotools files and bits that we had to support this.  So, for
introspection on Visual Studio via the project files, it is purely via
NMake at this point.

We want to share those listings with other non-autools build systems.

We want to make the sources listings for libgdk shared as well.

They are not used anymore, and are removed at this point.

This way, we can reuse these lists in other non-autotools Makefile-based
build systems.

This way, we can reuse this list in other non-autotools Makefile-based
build systems.

The Visual Studio projects have support for generating these items, so
we don't really need to distribute them with the sources.

Now that we have a frame clock in place, we should be able to drop
the beam-sync penalty prevention code as we should be aligning our
draws with CVDisplayLink.
Originally by Christian Hergert <chergert@redhat.com>, flushWindow
corrections and improvements by John Ralls.

Christian Hergert authored Sep 30, 2015 and John Ralls committed May 05, 2022

We don’t care about the other enums, fine to squash the warning.

This is to avoid getting X11 errors (thus aborting/exiting with a
failure) during rapid hotplugs, which may happen during e.g. CI testing.

The constructors in GDK only have a meaning for UNIX, on Windows
they are useless.

Thanks to Lukas Oberhuber for the patch.

Fixes #4726

Instead of performing keyboard layout substitution whenever we find a matching
entry in the registry, first try to load the original layout and only attempt
substitution when that fails.

See #4724

Fixes #1402

Signed-off-by: Thibaud CANALE <thican@thican.net>

Fixes #4690

Some Windows keymaps have bogus mappings for the Ctrl modifier. !4423 attempted
to fix this by ignoring the Ctrl layer, but that was not enough. We also need to
ignore combinations of Ctrl with other modifiers, i.e. Ctrl + Shift. For example,
Ctrl + Shift + 6 is mapped to the character 0x1E on a US keyboard (but it should
be treated as Ctrl + ^). Basically, always ignore Ctrl unless it is used in
conjunction with Alt, i.e. as part of AltGr.

Related issue: #4667