The @filename@ directive will use the full path of the file being parsed
for enumeration types; we should use @basename@, instead, as it improves
the reproducibility of the build by using only the file name.
Backport of 4040f76529bbf6d3310a71df2d37c9d95af83892 from main.
Apparently wantsUpdateLayer by itself isn't sufficient.
Also #ifdef wantsUpdateLayer for macOS X 10.8 and later; earlier
versions don't provide it.
Fixes#5393
CI and downstream packagers have been using the Meson build for a while
now, and we checked that it's idempotent to the Autotools build.
Having two build systems in tree doesn't make maintaining and releasing
GTK any easier, even if it's the stable/frozen branch.
Commit 0c1ea92219 took care of converting STRING/UTF8_STRING to mimetype
strings when letting selection targets known to the outer world through
wl_data_source/zwp_primary_selection_source_v1, but it missed the conversion
of those mimetypes back to the old atom strings, depending on the
application, the mimetype counterparts might not be known or handled, so
requests to paste from this app could go ignored.
Fixes: 0c1ea92219 - wayland: Translate STRING/UTF8_STRING selection atoms to mimetypes
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/5397
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.
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
