I didn’t expect this to be a thing that is only fixed recently. And the fix itself goes through a little bit back and forth. So I’d just like to share it since it is an interesting experience.

Between the communication of application and input method server. A common thing is application send a key event to input method and wait for the handling result of this event. Fcitx allows multiple different mode for it, including sync and async mode. By default it is async mode to avoid any block on the application side. But since we also support sync mode, we should keep two implementation have the same effect.

But in reality, we do behave the same under most circumstance, except when you bypass the key event and do some other thing at the same time. The reason behind this is actually easy to understand. Check the pseudo code below.

DBusCall call = inputContext->processKeyEvent();
call.waitForFinished();

DBusCall call = inputContext->processKeyEvent();
call.onFinished(processKeyEventCallback);

Imagine the input method issues commitString request at the same time. In the first sync case, the key event will be handled before the commitString, while the latter one will handle commitString before the key event.

If the key event is filtered, then there is no difference, but if the key is not filtered, then we will get two different result. For example, keyboard engine will show spell check within the preedit, but when you press space, the preedit will be commit to client and also the space key. You may say you can solve it by just combining the space key within the commit string request. Then what about a “left” key that doesn’t produce text? One way to solve it is to piggyback a rich result value instead of just a boolean value, but that would require more code change to existing interface. So in order to resolve this, we will force the input method to use the forward key interface to send the key back. Luckily, all event can be handled by the same way. The trick can be done within the last reserved event handler for key event.

Here’s the things changed with in the fcitx framework.

1. Engine can safely assume any commitString is handled before the key event. If engine want it the other way, it can use forward key request itself. This keeps the default behavior for all input context.
2. DBus based input context will block all the request sending the client until the request is returned. This ensures processKeyEvent is returned before the following request.
3. If there is any pending request, mark processKeyEvent request as true, and use forwardKey to re-send the key event to the client.
4. Within the input context code, tries to use the same data to forward key event if possible to avoid any conversion error.

一开始想了想要不要在标题写 Arch Linux，觉得还是必要的，因为目前只有 Arch Linux （和 Debian）出于套近乎的关系有了 Fcitx 5 全家桶。

1、需要安装的包

IM Module：fcitx5-gtk / fcitx5-qt

拼音和码表：fcitx5-chinese-addons

其他输入法可以参照 fcitx 4 的对应包名安装（例如 fcitx5-chewing 等）

配置工具：kcm-fcitx5（内含 fcitx5-config-qt 对于依赖纠结的人请去拍打 @felixonmars 拆包）

和 Fcitx 4 有一些文件冲突，不能同时安装。

2、环境变量和启动

和 Fcitx 4 一致即可，如果要多说几句的话那就是：

~/.xprofile (X11) 或者 ~/.bash_profile 或者 ~/.profile (SDDM 在 bash_profile 存在时只会读取 bash_profile)

export XMODIFIERS=@im=fcitx
export GTK_IM_MODULE=fcitx
export QT_IM_MODULE=fcitx

目前暂时没有自带 XDG 的自动启动文件，需要自动启动的话暂时可以选择 cp /usr/share/applications/fcitx5.desktop ~/.config/autostart/

3、配置

目前没有对拼音和码表的数据的迁移工具，需要重新训练，但应该用起来已经不错了。拼音的 bug（如果有）应该会比码表少一些。

当然如果你使用了别的并没有改变库的其他输入法数据基本可以直接拿过来用。路径会有所不同，在 fcitx 5 中路径将变为更加标准的 ~/.local/share/fcitx5 ，配置文件还是主要存放在 ~/.config/fcitx5。

默认启动后并不会添加其他输入法，可以通过配置工具进行添加。

4、功能

关于键盘布局方面有较大区别，系统键盘布局现在和一个新的「分组」的概念绑定，同一个分组里的键盘布局是直接通过 xkbcommon 进行模拟，而不是采用修改系统键盘布局的方式。因此也不再有针对 ~/.Xmodmap 的支持，如果需要修改常见的设置（例如交换 Ctrl Esc）建议使用 xkb option 进行修改。

拼音相比原来的「自带拼音」有不少新增的功能，例如多词库，Emoji等，可以通过配置工具那边自行浏览。