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.
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.
Recent changes in GTK default input method
makes ~ char to start as dead key, that's
why filechooser stopped detecting it for the
keybinding to open location entry.
We also make sure '~' appears in the location
entry (instead of being emtpy).
Fixes#4911 for GTK3
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
