インプットメソッドフレームワーク

2022年現在、fcitx5 と ibus が強いイメージ。 SCIM などは最近はあまり使われていないかも。

ibus

別プロセスで変換エンジンは動く。

DBus という汎用的な IPC の枠組みの上で動くのでプログラミング言語に依存しない。とはいえ、ibus のメソッドを呼んでつくらないとしんどいので、結局は ibus の C のライブラリか python のライブラリを使っている実装ばかりである。

akaza では ibus の C ライブラリを FFI でコールしている。

(ibus-dl という crate もあったがラップされているメソッドが少ないので採用していない。)

IBus のメリットは、変換エンジンそのものは外部プロセスで動いているという点で、変換エンジンが SEGV しても、IBus 側そのものは生き続けることができる。 akaza の開発時のように、変換エンジンとUIを並行して開発したいような場合には安心感がある。

fcitx5 は C++ でエンジンを書いて、dlopen する感じの実装。対応するなら、C++ で UI をガッツリ書いて、rust 側を呼び出す感じで実装するのがスムーズにいきそう。

dlopen する形なので、日本語のかな漢字変換のように複雑なプロセスが走る場合は fcitx5 側を巻き込んでプロセスが死んでしまう気がする。なので、ibus を先に対応しています。