ClutterInputFocus/GtkIMContext uses char based offset for
delete_surrounding, however, text_input_v3 uses byte based offset for
it. Currently only GTK with mutter can work correctly via text_input_v3
because they both forget to convert between char based offset and byte
based offset.
This commit fixes it in GTK by converting byte based offset to char
based offset with the UTF-8 encoded surrounding text.
Fixes <https://gitlab.gnome.org/GNOME/gtk/-/issues/4566>.
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.
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.
If we get consecutive preedit string updates that announce a NULL
string, we still do end up issuing ::preedit-changed with those.
Ignore changes from NULL to NULL, it is the other combinations which
must issue this signal.
For reasons that only apply to the old serial handling, asking for
the surrounding after IM changes resulted in lazy handling of
commit() afterwards.
With the recent interpretation of serials, this problem became more
apparent, since it is in fact very likely that the last interaction
step after an IM change is notifying of the changed surrounding
text after the IM change was applied.
Make handling of surrounding text similar to caret position changes,
always commit() after the state change, but skip through non-changes.
This makes the compositor state fully up-to-date after an IM change.
(cherry-picked from commit eb7c78aa4896b1d36fa09a3e68c942730b233f74)
Tweak the preedit text we get from IBus (via the compositor) to
match what GtkIMContextSimple produces for Compose sequences now.
This provides a unified experience.
In the paths where len > MAX_LEN and cursor/anchor are separated by
at least MAX_LEN from text edges, we were clamping the right end of
the surrounding string at MAX_LEN. Oops.
This end anchor may go as far as the string length, although just
up to len - MAX_LEN in real terms (due to the condition above that
caches cursor/anchor positions being near enough the text end).
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/2565
To find the middle of the string, we should check both cursor/anchor.
This is actually a backport of commit 8fc360dac5e4 in master.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/2522
GtkIMContext get_preedit_string should return cursor position counted
in characters, but cursor_begin here is counted in bytes. This add the
missing conversion.
Specifically it is avoided to be toggled if:
- Just received focus (in order to preserve OSK state across focus changes)
- Moving cursor around. Still allow some jitter as perfect accuracy is not
possible.
Closes: https://gitlab.gnome.org/GNOME/gtk/issues/1277
Before this patch, imwayland would assume that text-input enter and leave events follow the general (wl_keyboard) focus, and was unable to handle the situation where they would not be provided at the same time.
Fixes terminal emulator misbehaviour as outlined in https://gitlab.gnome.org/GNOME/gtk/issues/1316, which was introduced in 49b17e6c. The original commit cleared preedit text by setting it to an empty string, which still counted as existing preedit. The fix sets preedit string to null, which is correctly understood as not present.
There may be situations where this might get called while the
currently focused context just went away (eg. after setting the
text widget unsensitive).
Closes: #1317
This fixes a potential leak of a PangoAttrList that is set when chaining
up to the parent get_preedit_string(). We check to see if the attr list
was created and reuse it instead of leaking the previous value.
If the parent get_preedit_string implementation returns a nonnull
zero-length string, then we ignore it, which is almost fine. We have to
free it, though.
Fixes#1174
Fixes two things: 1) As GTK+ can be coerced into using the wayland IM
module despite the compositor not implementing the interface, all paths
not checking for global state before sending requests are prone to
crashes, this one fell hit this pitfall.
And 2) ensures the tap gesture only triggers TOGGLE_INPUT_PANEL if the
widget IM is focused. This is a possibility on eg. WebKit pages, where
its IM is only focused as long as a form element in the page is focused.
Tapping elsewhere shouldn't toggle the OSK.
https://gitlab.gnome.org/GNOME/gtk/issues/114Closes: #114
This IM context implementation goes through the gtk-text-input protocol,
leaving up to the compositor the actual interaction with IM engines. If
the protocol is not offered by the compositor, GTK+ will fallback to the
IMs as specified through GtkSettings.
