Split iBus? (or Fcitx, Fcitx5, whatever)


For whom uses any input method framework on Qubes OS (ex. who writes CJK everyday, a heavy user of emojis, an ibus-typing-booster enthusiast, etc.), the notification area ends up something like the following screenshot (using Fcitx5, but this is independent to the framework as long as it uses the notification area):


If I understand correctly, the GUI domain (sys-gui) will not improve this situation, as the IM module shall be loaded to application processes as a plugin of the corresponding GUI toolkit. Instead, one needs a proxy for IM framework(s) forwarding messages between applications and input method processes to a dedicated domain, say sys-im.

To be fair, the current behavior has its own advantages. For example, you want to register a lot of technical terms to the user dictionary on the work domain but not on the personal domain in order not to let the candidate window show such words when you chat with your friends. Separation of input method configuration (user dictionary, input history, etc.) is preferred for some important use cases.

What do you think? I believe that I am not the only person managing seven or such instances of IM configuration with Qubes OS. I have not tried salt yet, does that help us in this situation too?

right now i have 2 domains i communicate in german and i use setxkeymap de|us to switch between them; which works fine for me.

1 Like