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: 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>
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.
During text 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.
Also, fix a bug during GtkEventControllerKey::im-update where the condition
on cursor position editability to reset the IM context was inverted.
Currently, the wayland IM context sends zwp_text_input_v3.commit from
a number of places, and some of them with partial data. In order to
make client state updates "atomic" and complete, make the communication
happen over an unified notify_im_change() function that happens on
a narrower set of circumstances:
- The GtkIMContext is reset
- The GtkIMContext is just focused
- The gesture to invoke the OSK is triggered
- The IM context is reacting to changes coming from the compositor
Notably, setting the cursor location or the surrounding text do not try
to commit state on their own, and now will be flushed with the corresponding
IM update or reset. But also, these requests won't be prevented from
happening individually on serial mismatch, instead it will be the whole
state commit which is held off.
With these changes in place, all client-side updates are notified
atomically to the compositor under a single .commit request.
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.
