Created attachment 1832549 [details] Video showing the problem using ibus-m17n with si-wijesekera [mfabian@fedora ~]$ cat /etc/fedora-release Fedora release 35 (Thirty Five) [mfabian@fedora ~]$ rpm -q ibus ibus-1.5.25-4.fc35.x86_64 [mfabian@fedora ~]$ rpm -q ibus-m17n ibus-m17n-1.4.7-1.fc35.x86_64 [mfabian@fedora ~]$ rpm -q ibus-typing-booster ibus-typing-booster-2.14.13-1.fc35.noarch [mfabian@fedora ~]$
Created attachment 1832552 [details] Another video showing the same problem using ibus-typing-booster. In the video I type "test " with the option “Avoid using the forward_key_event()function” off and than again with that option on. When typing in gedit, this makes no difference, both with that option on and off,the result of typing "test " is always "test ". But when using XIM, it works only when forward_key_event() is used to send the space, not when "return False" is used. I this video I use xterm as an example for a program using XIM, but one can reproduce the same problem with any program using XIM, for example also with emacs. When "return False" is used to send the space, typing "test " gives the result " test", i.e. the committed text and the space are reversed.
Ibus-hangul also uses forward_key_event() to send the spaces between words for this, reason. Long ago ibus-hangul used "return False" and then had the same problem. ibus-hangul has no option for this though, ibus-typing-booster is an especially good test case because there is an option in the setup tool to choose whether to use "forward_key_event()" or "return False".
See also https://github.com/ibus/ibus-m17n/issues/27 The problem in ibus-m17n described there is caused by committing something and then passing a space with "return False". This does not work correctly in XIM and because emacs uses XIM this causes the problem in Emacs.
Currently ibus-x11 works with sync key events by default since Java X11 clients causes SEGV with async key events and some X11 applications spend time and does not work with async key events. Unfortunately libX11 does not sort key events with the time values. https://github.com/ibus/ibus/commit/b58351ec2f7c057dcfe0aff883064039702a56d7 https://github.com/ibus/ibus/issues/1713 https://github.com/ibus/ibus/issues/1847 The workaround is to run ibus-daemon --xim with IBUS_ENABLE_SYNC_MODE=0 . On the other hand, I suggest to delete forward-key-event API to handle FALSE key events in GTK4. Those requests are conflicted now by each other. Solution #1 - Delete forward-key-event in each ibus engines to handle FALSE key events - Ask each Java applications to cause SEGV with async key events - Bring back async key events to ibus-x11 The risk is that we don't touch each Java applications and depends on the Java developers efforts Solution #2 - Change focus-in API in IBus engines to get the client names and context names to handle the forward-key-event API by client names The risk is that each IBus engine need to change focus-in API between IBus versions.
> 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 events 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 client. But to fix the problem in ibus-m17n (see https://bugzilla.redhat.com/show_bug.cgi?id=2013610#c3 ) 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.
This message is a reminder that Fedora Linux 35 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '35'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 35 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Problem is unchanged in Fedora 37.
(In reply to Mike FABIAN from comment #1) > Created attachment 1832552 [details] > Another video showing the same problem using ibus-typing-booster. > > In the video I type "test " with the option “Avoid using the > forward_key_event()function” off and than again with that option on. > > When typing in gedit, this makes no difference, both with that option on and > off,the result of typing "test " is always "test ". > > But when using XIM, it works only when forward_key_event() is used to send > the space, not when "return False" is used. > > I this video I use xterm as an example for a program using XIM, but one can > reproduce the same problem with any program using XIM, for example also with > emacs. > > When "return False" is used to send the space, typing "test " gives the > result " test", i.e. the committed text and the space are reversed. ibus-typing-booster has a workaround for this problem now: https://github.com/mike-fabian/ibus-typing-booster/commit/90846be1e68b6df5265ef4f1742ad3f0d86138de it commits the space instead of forwarding it or returning false. Therefore, the above procedure to reproduce the problem does not work anymore. But if I disable that workaround in ibus-typing-booster, the problem is still there.
We integrate the new process-key-event in ibus-1.5.27-6.fc38 and ibus-typing-booster can check IBUS_CAP_SYNC_PROCESS_KEY_V2 capability. Currently we have no plan to update Fedora 37.