Hi, Here is my thought on my practical and non-invasive solution.
On Sat, 2021-11-20 at 23:12 +0100, Gunnar Hjalmarsson wrote: > On 2021-11-20 21:53, James McCoy wrote: > > On Sat, Nov 20, 2021 at 11:37:14PM +0900, Osamu Aoki wrote: > > > If I understand correctly, upstream chose to disable ibus feature > > > if GLFW_IM_MODULE is not set to ibus. So ibus is opt-in feature. > > > Reverting that feature choice is one option for Debian maintainer > > > can do indeed. This is a risky path most maintainers hesitate. > > > > Yeah, this isn't something I would patch. > > Fair enough. And given that, it would not be appropriate to bypass the > restrain in Debian via im-config. > > > > Since kitty has kitty.conf, a non-confrontational approach may be a > > > patch to add one configuration option in kitty.conf to enable ibus. > > > So ibus support is still opt-in feature. > > > > That sounds like a reasonable approach, if someone would like to > > propose a patch/PR to Kovid. I'm not familiar with IME topics, so I > > don't think I would be in a good position to advocate for that. > > Seems like that has already been proposed and turned down: > > https://github.com/kovidgoyal/kitty/issues/3206 > > So maybe users who want IME support in kitty need to get used to set > that environment variable. I guess the kitty upstream's negative impression on ibus/fcitx5 for dropped key inputs comes from the well known ibus/fcitx5 daemon related problem using xim as the communication protocol and probably not applicable if dbus is used to call ibus/fcitx library. The upstream's latency concern with dbus may be negligible compared to how fast we can type but it is true that adding any complication slows things. So we better not to touch kitty code. But kitty terminal displaying CJK-characters with millions of complicated shapes may be the one benefit most by using GPU. So we as a distribution should offer easy access to this feature at least as an opt-in feature. Considering kitty is the only user of GLFW_IM_MODULE variable on Debian and it shouldn't be turned on by default according to the upstream, I propose to add following content as README.Debian in the Debian package of kitty. ---------- # Input Method support You can enable input of non-Latin characters to the kitty terminal as follows: 1. Install required a set of input method program based on ibus or fcitx5 2. Place the following file named "kitty" in PATH (e.g., ~/.local/bin or /usr/local/bin) 3. Meke "kitty" script an executable. (`chmod 755 kitty`) --- #!/bin/sh -e GLFW_IM_MODULE=ibus exec /usr/bin/kitty "$@" --- fcitx5 uses the same communication protocol as ibus. So you use "ibus" even for "fcitx5". Other input method infrastructure such as "fcitx" and "uim" are not supported. ---------- For im-config, I think it is about time to kill upstream non-supported known broken xim support by dropping to start daemon from im-config which sets how Debian behaves as installed. xterm and rxvt may loose CJK input but we will get less bug report on ill-configured modern GTK/Qt apps using xim.
