Even though the argument is non-nullable, GTK sometimes incurs in that
by itself by destroying the surface while the event is in flight. This
is the case of popping down a GtkDropdown. When this happens we simply
ignore the crossing event, but we should let it through instead, the
compositor did not send it in vain and we possibly still have pointer
state to undo.
Drop the surface checks, so that the event is propagated along GTK.
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.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/5200
Fixes: 5b78fe2721 (gtktextview: Also reset IM context after IM...)
Fixes: 7c0a395ff9 (gtktext: Also reset IM context after IM...)
Fixes: 52ac71b972 (gtktextview: Shuffle the places doing IM reset)
Fixes: 9e29739e66 (gtktext: Shuffle the places doing IM reset)
The X11 backend can mark modifiers like Shift as consumed even if they
aren't actually active, which seems to be something to do with making
shortcuts like `<Control><Shift>plus` and `<Control>plus` work as
intended regardless of whether the plus symbol is obtained by pressing
Shift and a key (like `+/=` on American, British or French keyboards)
or not (like `*/+` on German keyboards).
However, this can go badly wrong when the modifier is *not* pressed.
For example, terminals normally have separate bindings for `<Control>c`
(send SIGINT) and `<Control><Shift>c` (copy). If we disregard the
consumed modifiers completely, when the X11 backend marks Shift as
consumed, pressing Ctrl+c would send SIGINT *and* copy to the clipboard,
which is not what was intended.
By masking out the members of `consumed` that are not in `state`, we
get the same interpretation for X11 and Wayland, and ensure that
keyboard shortcuts that explicitly mention Shift can only be triggered
while holding Shift. It continues to be possible to trigger keyboard
shortcuts that do not explicitly mention Shift (such as `<Control>plus`)
while holding Shift, if the backend reports Shift as having been
consumed in order to generate the plus keysym.
Resolves: https://gitlab.gnome.org/GNOME/gtk/-/issues/5095
Bug-Debian: https://bugs.debian.org/1016927
Signed-off-by: Simon McVittie <smcv@debian.org>
The filetransfer protocol says to use
application/vnd.portal.filetransfer, but I used
application/vnd.portal.files when I implemented the
protocol. Oops.
This commit dds the correct mimetype, but we still
support the old one to preserve interoperatibility
with existing flatpaks using GTK 4.6.
Fixes: #5182
We need to register the portal mime types before
the others to prefer them, doing this call async
messes up that ordering.
This is effectively reverting 69fb3648b2
When some of the Emoji have been filtered out by
a search term, arrow keynav would behave oddly and
get stuck in invisible sections. Fix this by ignoring
any filtered out children when moving between
sections for arrow keynav.
Fixes: #5076
Test that we can expand and collapse a row, and then
add another child below it, without crashing.
Adapted from the testcase in #4595.
This tests the fix in the previous commit.
When we collapse a node, we clear out the children,
but we were not disconnecting the signal handler on
the child listmodel, leading to bad outcomes when
that model is persistent and changing.
Fixes: #4595
Commit adba0b97 fixed missed pointer crossings by using a helper function that
was already present and looked like did everything that was needed. However
this function was oriented to keyboard focus and it also did update the related
widget state. Doing these changes on pointer-based crossing was misuse, and
could cause weird interactions with keyboard focus management.
Fix this by using gtkmain.c gtk_synthesize_crossing_event() that is in fact
oriented to pointers.
Fixes: adba0b97 (gtkwindow: Synthesize pointer crossing events on state changes)
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/5094
The inner loop in gtk_paned_set_focus_child() tries to find the
topmost GtkPaned, however, if the `w` variable ends up becoming
NULL after bubbling up the entire GtkWidget hierarchy, this loop
never breaks.
Check for NULL in this loop.
Closes https://gitlab.gnome.org/GNOME/gtk/-/issues/5094
Instead of passing an event and figuring out coordinates from it, pass
directly the toplevel coordinates so that we can use this outside event
handling.
All callers have been updated to pass the coordinates, in practical effects
they were already based on the GtkNative.
When widgets go mapped/unmapped, we repick but don't generate crossing
events. Since there could be stateful controllers that use those in
the previously picked widget (e.g. GtkEventControllerMotion), skipping
those breaks their state.
Ensure to send the relevant crossing events on every situation that
changes the pointer focus, so these controllers get a fair opportunity
to undo their state.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/2877
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.
Fixes: 52ac71b972 ("gtktextview: Shuffle the places doing IM reset")
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/5133
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.
Fixes: 9e29739e66 ("gtktext: Shuffle the places doing IM reset")
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/5133
We want to claim the event sequence in the click gesture when appropriate,
such as activating a row or clicking an editable cell, but this is currently
done too early, preventing other gestures for drag-and-drop and rubberband
selection entirely.
Fixes#3649Fixes#3985Fixes#4669
