On Sun, Jun 6, 2021 at 4:51 AM Shengjing Zhu <z...@debian.org> wrote: > > On Sun, Jun 6, 2021 at 4:06 AM Gunnar Hjalmarsson <gunna...@debian.org> wrote: > > > > If both fcitx 4 and fcitx 5 are installed, the IM_MODULE value "fcitx" > > would result in a fcitx 4 im module being loaded when using fcitx 5. We > > have so far assumed that that would be a problem, if I understand it > > correctly, and that's the reason why the fix of this bug was postponed. > > > > Question: How would it be a problem? > > > > Situation has changed since fcitx5 5.0.4, which includes a compatible > frontend for fcitx4 module. > https://salsa.debian.org/input-method-team/fcitx5/-/commit/7780c8f7f9bcde2fcff6ae7fc3ce5ab2c40ebe63 > > The origin purpose is to support property software which only ships > with fctix4 modules, as well as snap, flatpak, etc, which can't use > the system library.
Correct: better support. As without fcitx4front, it also has ibusfront, which means using ibus modules in these software, then fcitx5 can talk to them. But you always need a proper env to tell these software to choose an input module. You can set IM_MODULE to fcitx, or ibus. But setting fcitx5 just makes these software fail to find the right input module. -- Shengjing Zhu