The merge request !5235 switched tests and examples from
G_APPLICATION_FLAGS_NONE, which has been deprecated in GLib 2.74, to
G_APPLICATION_DEFAULT_FLAGS. Sadly, it was done unconditionally, which
means we'd have to bump the required version of GLib.
To avoid that, let's just use the numeric value of the enum member.
This fixes Autotools builds that disable Wayland, such as non-Linux
operating systems and the minimal "udeb" (micro-.deb) package used in
Debian's installer.
Signed-off-by: Simon McVittie <smcv@debian.org>
GtkSettings/X11 takes the values as provided by
XSettings. Unlike other backends, the values of
XSettings are in physical size (that's because
X11 doesn't support mixed-DPI setups anyway).
Take that in account when retrieving the cursor
size in gtk_tooltip_position ().
Note that this discrepancy between the X11 and
other backends has been fixed in GTK4.
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/5223
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: fb68600d88
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: 4dcacff312
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: 999509be61
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: 4d741bac98
Signed-off-by: Joan Bruguera <joanbrugueram@gmail.com>
Doing reset() on the text widgets after commit and delete_surrounding
is still too eager for some IMs (e.g. those that expect being able
to commit text while keeping a preedit buffer shown).
However, reset() is more of a "synchronize state" action on Wayland,
and it is still desirable to do that after changes that do come from
the IM (e.g. requesting the new surrounding text and cursor/anchor
positions). Notably here, the text_input protocol may still come up
with a preedit string after this state synchronization happens.
Shuffle the code so that the text widgets do not reset() the IM
context after text is deleted or committed, but the Wayland IM does
apply its practical effects after these actions happen. This keeps
the Wayland IM fully up-to-date wrt text widget state, while not
altering the ::commit and ::delete-surrounding-text behavior for
other IM context implementations.
When the IM commands the GtkText to delete text, the cursor position
would change, and so would the surrounding text. Reset the IM context
so that these updates are properly picked up by the IM.
Fixes backspace key behavior in the GNOME Shell OSK, since that relies
on the surrounding text being properly updated for the next iteration.
When the IM commands the GtkText to delete text, the cursor position
would change, and so would the surrounding text. Reset the IM context
so that these updates are properly picked up by the IM.
Fixes backspace key behavior in the GNOME Shell OSK, since that relies
on the surrounding text being properly updated for the next iteration.
Resetting the IM on IM updates is too eager and indeed the simple
IM context doesn't like that this happens in the middle of dead
key handling.
We however want to reset the IM after actual text buffer changes
(say, a committed string) moved the cursor position, altered the
surrounding text, etc. So that the IM implementation does know to
update its state.
Since there is going to be an actual IM reset anyways, it does
no longer make sense to try to preserve the old priv->need_im_reset
status during commit handling.
Resetting the IM on IM updates is too eager and indeed the simple
IM context doesn't like that this happens in the middle of dead
key handling.
We however want to reset the IM after actual text buffer changes
(say, a committed string) moved the cursor position, altered the
surrounding text, etc. So that the IM implementation does know to
update its state.
During entry widget manipulation (inserting or deleting text via keyboard)
the IM context is reset somewhat early, before the actual change took place.
This makes IM lag behind in terms of surrounding text and cursor position.
Shuffle these IM reset calls so that they happen after the changes, and
ensure that the IM is actually reset, since that is currently toggled on
a pretty narrow set of circumstances.
