--- Comment #5 from Mike FABIAN <mfabian(a)redhat.com> ---
On the other hand, I suggest to delete forward-key-event API to
handle FALSE key events in GTK4.
- Delete forward-key-event in each ibus engines to handle FALSE key
I think we need to find a way to make forward-key-event work even with GTK4,
forward-key-event is very important for many things, it really has to work.
And for this bug here, not using forward-key-event does not help. If async key
events are used with ibus-x11, *both* returning False *and* forward-key-event
work correctly for the space after a commit.
Solution #2 sounds interesting to me, it would be nice if input methods could
know about the client names and do stuff a bit differently depending on the
But to fix the problem in ibus-m17n (see
) this would mean that
ibus-m17n should use forward-key-event instead of "return False" when xim is
used. This is fine with me, if it becomes possible in the focus-in API to
detect whether the client uses xim, then I would change ibus-m17n to always use
forward-key-event in that case instead of "return False".
Would the new API on focus-in give information which toolkit is used (Qt4, Qt5,
Gtk3, Gtk4, X11 (XIM)) or would it give client names like "xterm" or
"google-chrome"? Both might be useful to help the input method to optimize the
behaviour based on information about the client.
You are receiving this mail because:
You are on the CC list for the bug.