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.
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.
Make the messages to show the configuration when we (re-)generate the
demos.h.win32 and Visual Studio projects show at the beginning, and make the
messages clearer.
This adds rules using xgettext to generate gtk30.pot and
gtk30-properties.pot.
Currently, the XGETTEXT=... must be supplied, since it will likely come
from a MSYS2 or Cygwin installation on Windows.
This will help us get closer to support building more directly from a
GIT checkout with the Visual Studio projects
This allows one to (re-)generate clienthtml.h and broadwayjs.h that is needed
to build broadwayd with the NMake Makefiles. Currently, since these headers
are currently dist'ed, the rules added here are mainly of use to build from a
GIT checkout.
...when running on a system with nVidia graphics with Nahimic installed, since
a known issue within the graphics drivers and/or Nahimic can cause random
crashes and issues when OpenGL (G[t|d]kGLArea) is being used.
This will close issue #4113--sadly, this issue is an issue that is beyond our
reach to try fixing within GTK.
