This way we can keep the same wayland-protocols requirement, so the latest GTK3
still builds on distributions shipping older versions of wayland-protocols,
such as Debian Bullseye.
Should fix CI builds as well.
Double check the GdkSurface has a wl_surface before using it as the activation
token source, since we cannot use NULL surfaces here.
Fixes: https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/1862
Backport-of: 4b41d4f78ce71b60f0d51837cd1b6a1b346d679d
Signed-off-by: Joan Bruguera <joanbrugueram@gmail.com>
Use a separate queue to dispatch the token object exclusively, just like we
do on the GdkSurface activation paths.
Backport-of: fb68600d88d4d334f7da7d079b106a1ef14503a6
Signed-off-by: Joan Bruguera <joanbrugueram@gmail.com>
Currently, we have all the plumbing in place so that GTK consumes the
startup notification ID when focusing a window through the xdg-activation
protocol.
This however misses the case that a window might be requested to be
focused with no startup ID (i.e. via interaction with the application,
not through GApplication or other application launching logic).
In this case, we let the application create a token that will be
consumed by itself. The serial used is that from the last
interaction, so the compositor will still be able to do focus prevention
logic if it applies.
Since we already do have a last serial at hand, prefer xdg-activation
all the way over the now stale gtk-shell focusing support. The timestamp
argument becomes unused, but that is a weak argument to prefer the
private protocol over the standard one. The gtk-shell protocol support
is so far left for interaction with older Mutter.
Backport-of: 4dcacff3120d5c1cef888061dbc42f5fbe093a58
Signed-off-by: Joan Bruguera <joanbrugueram@gmail.com>
When using xdg_activation we need to keep the id around until we send
the first activate to signal succesful startup.
Backport-of: 999509be619bfa0f50a549489b5ab5c890b574fa
Signed-off-by: Joan Bruguera <joanbrugueram@gmail.com>
Tools like gtk4-launch can't set surface on the activation token so
don't require it. If the compositor requires it we can't do anything
about it anyway. This avoids a critical:
(gtk4-launch:23497): Gdk-CRITICAL **: 17:07:24.704: gdk_wayland_surface_get_wl_surface: assertion 'GDK_IS_WAYLAND_SURFACE (surface)' failed
Fixes: be4216e051 ("gdk/wayland: Support the xdg-activation wayland protocol")
Signed-off-by: Guido Günther <agx@sigxcpu.org>
Backport-of: 4d741bac98f906796d61eebfb4f74f5b1cecb2b6
Signed-off-by: Joan Bruguera <joanbrugueram@gmail.com>
Sometimes, there may be motion events left in the queue, because at the
time of handlign these motion events the GDK_FRAME_CLOCK_PHASE_FLUSH_EVENTS
phase is not requested.
Ensure that, when finding motion events on a window that does not disable
motion compression, the events are anyways flushed, so they can be processed
early by the window/widget event handlers.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/4946
Since the GDK API layer in 3.x is considerably tied to X11 details,
it makes sense to provide this bit of translation in case the app
uses these exclusively and does not use actual mimetype strings.
Provide this bit of translation of X11 selection atoms to mimetypes.
While at it, use the right zwp_primary_selection_source_v1 API with
primary selection data sources. From the looks of it, this just
happened to work.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/5217
This adds a private GDK API that GTK calls using GDK_PRIVATE_CALL(). It
is more or less a copy of the GdkSurface::titlebar_gesture() API, and
achieves the same. If the backend or compositor doesn't support titlebar
gestures, the existing path is used as a fallback.
gdk_wayland_gl_context_realize properly checks for GLES and uses
eglBindAPI with the proper API, but before that init is always called
with regular GL interface which is not implemented for many embedded
devices.
This was fixed in GTK 4 with commit 482845b02705 ("wayland: Remove
initial GL API bind"), but that commit cannot easily be applied because
the current version queries some GL properties during init so we would
need to backport more for it to be applicable.
This patch takes the minimal approach of initializing GLES context,
allowing the gtk3 demo OpenGL test (and real applications) to work
when GDK_GL=gles is set.
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/3028
gdk_wayland_drop_context_update_targets gets targets from the
selection's offer. In order to ensure that the drop context has
up-to-date targets, update the selection's offer before updating
targets.
This fixes drag-and-drop not working reliably when running Firefox in
Plasma Wayland session.
Add "stylus" to the list of substrings in a device name that cause it to be recognized
as a GDK_SOURCE_PEN device (previously "wacom", "pen" and "eraser"). Some devices
just use "stylus" in their name, and are otherwise recognized as
GDK_SOURCE_TOUCHSCREEN instead.
Fixes#4394.
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.
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
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.
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.
