The macOS WM has no root window. We fake one with a 1x1 window at the
origin that has no associated NSWindow. If the pointer is not on a
realized GdkWindow the hierarchical search will place it in the root
window even if it's nowhere near it. That's not valid, but returning it
from find_toplevel_under_pointer prevents Gdk from discovering when the
pointer is really over a GdkWindow. Return NULL instead so that the window
discovery is re-performed.
This seems to have regressed despite the GTK code not having changed,
possibly as a result of changes in another package, and it seems to be
the reference rendering rather than the test output that changed.
This will let us distinguish between "fails by small differences caused
by rounding/i387" and "completely different result", without having to
move the whole build system to Meson, which seems like one variation too
many during a transition.
Since GLib 2.73.0 it can only be called once per process.
Based on commit 78c153ae in GTK 4, but combining the icontheme test's
two custom log writers into one log writer that serves both purposes,
to avoid the need for a subprocess.
Co-authored-by: Matthias Clasen <mclasen@redhat.com>
Resolves: https://gitlab.gnome.org/GNOME/gtk/-/issues/5119
When a Gtk.Popover loses the focus, it blocks the grab_notify
signal from the associated widget, and it unblocks it when it
regains the focus. To know whether the signal is or not blocked,
it uses the priv->grab_notify_blocked flag.
On the other hand, when the method update_relative_to() is
called, all the signals connected to the old associated widget
are disconnected, and connected to the new widget.
Unfortunately, the priv->grab_notify_blocked flag isn't updated,
which means that if update_relative_to() is called while the
Gtk.Popover doesn't have the focus (for example, because the
user switched into another application), when the focus is
regained, the code in window_focus_in() will see that
priv->grab_notify_blocked is TRUE and will unblock the handler;
but that handler wasn't blocked because the one that was blocked
was disconnected when update_relative_to() was called. This
shows a WARNING in the console:
GLib-GObject-WARNING **: ../../../gobject/gsignal.c:2692: handler '5146' of instance '0x556912f84f40' is not blocked
This patch fixes this.
Fix https://gitlab.gnome.org/GNOME/gtk/-/issues/4777
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: https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/534#note_1526935
Allow one to specify INCLUDEDIR and LIBDIR to locate the headers needed
for generating sources, if they are not under $(PREFIX)\include and
$(PREFIX)\lib, repsectively.
... in the gtk-3 Visual Studio project. This will allow one who wishes to use
the font features items that uses the older PangoFT2-based APIs that is used
before Pango 1.44.0 and HarfBuzz-2.2.0 an easier way to do that, by
regenerating the gtk-3 project files with the necessary items enabled.
The font features demo still needs to be explicitly enabled, though, as
before.
This adds instructions to aid one to build with the Visual Studio projects
directly from a GIT checkout, or to re-generate the project files with
various options and features enabled (which are not enabled by default
in the release tarballs).
This adds a NMake Makefile to generate the needed items that are normally
generated during `./configure`, as well as to generate the full Visual Studio
projects and property sheets, so that one can use the Visual Studio projects
to build GTK directly from a GIT checkout. A 'clean' target is also provided
to remove these generated artifacts. This also generates the headers that are
needed to build broadwayd, since they are currently dist'ed with the tarballs
but are not in the GIT repo.
This will not be dist'ed, as this is primarily meant for GIT checkouts only.
...and use that info if no version and/or interface age was specified. This
way, we can use this script to help bootstrap builds from Visual Studio
projects directly from a GIT checkout.
...into a NMake Makefile snippet of its own, to make things clearer and easier
to maintain. The regenerating target should still be invoked using
generate-msvc.mak.
This adds rules to allow (re-)generating the libgtk and libgail-util Visual
Studio projects, which needed some tinkering since we don't want to fall into
the nasty U1095 error.
This extends the support to generate all the GDK Visual Studio projects, which
include GDK, GDK-Broadway and broadwayd, in addition to GDK-Win32. The rule
to regenerate the GDK-Win32 project is now changed to regenerate all GDK
projects, with or without EGL support in GDK-Win32.
Also, remove extraneous blank spaces in win32/vs10/broadwayd.vcxprojin to avoid
errors when generating the full VS2010+ broadwayd Visual Studio projects with
this update.
Use inference rules and re-group things a bit, to make things cleaner and
clearer.
This will allow one to quickly re-generate the Gdk-Win32 Visual Studio
projects with or without EGL/libANGLE support. Since some rules are shared
with the ones that we use to generate the gtk3-demo projects, clean things
up a bit.
We don't need to track the project files and property sheets that are generated
from their templates, and we don't want to track the demos.h(.win32) that are
mainly used for the Visual Studio builds, which are also generated.
