Comment 22 for bug 1928360

On 2021-06-05 06:32, James Henstridge wrote:
> It's probably going to be easiest to see if we can get things
> working with a core20 based platform snap though, since we have
> fcitx5 packages there (albeit for a git prerelease version).

Is there such a snap you could point me to so I can test?

> For the core18 based platform snaps, we would need to backport the
> fcitx5 packages themselves. Alternatively, I wonder if we could get
> away with symlinking the old module name to the new one?

The latter would be equivalent to assign "fcitx" instead of "fcitx5" to the IM_MODULE variables if I understand it correctly.

The Fcitx 5 folks upstream recommend "fcitx" for IM_MODULE. The reason why Debian/Ubuntu currently set "fcitx5" is to deal with systems during a transition period where both fcitx 4 and fcitx 5 are installed. In such cases "fcitx" would result in the fcitx 4 im modules being loaded also when the user runs fcitx 5, and we have assumed that that might be problematic.

OTOH, my successful test with Chromium indicates that it works. Now I'm not the right person to evaluate it, since I'm not an input method user, and that's what I want to talk with the Chinese developers in Debian's input method team about.

@handsome_feng: Maybe the Kylin team can help to test this, considering that Kylin will be shipped with both fcitx 4 and fcitx 5 in 21.10. If you override im-config and enforce GTK_IM_MODULE and QT_IM_MODULE to be assigned "fcitx" also when using fcitx 5, do you see any adverse side effects?