Gaps between Wayland and Fcitx (or all Input methods).

Though some people have no problem (or, only few problems) about using fcitx (to be more specifically version 4) with wayland, but the truth is there are still lots of problems left to be addressed.

The truth is, wayland is not yet ready for input method.

1. Generic input method protocol is not widely adopted.
   In the old good X11 world, there is a protocol call XIM. No matter how bad it is, it widely used and adopted by nearly all applications. But as for wayland’s protocol “text-input”, the current situation is:
   – Gtk3 doesn’t support it.
   – Qt5 support a not-upstreamed version 2.
   – EFL / weston support the official version in wayland-protocols.
   – SDL2 doesn’t support it.
   – Weston’s reference client side implementation has critical bug.
   What does this mean? This means even you’re using wayland + (GNOME/KDE) for now, you’re still using the old im module via DBus.
2. The generic input method protocol is bad.
   It is weird that in wayland world, key repetition is a task of client. But the problem is, it even becomes a work for input method. Fcitx 5 for now is the only implementation handles key-repetition correctly. But I don’t even care about this because I don’t even have a real application to test this feature. (You need a patched version for weston-editor to play with it).Also, the wayland input context will be destroyed once it get unfocused, which makes it unable for input method server to track different window and keep different input state for different window (e.g. different window + different im will need this feature) .
3. The window positioning issue.
   In Wayland world, there’s no way for a non-compositor window to place the window by abstract coordinates (x, y). Also there is no way for a non-compositor window to know about its own location. But for input method, you need to display a window at the position of cursor. The “input-method” protocol in wayland allows you to assign a surface as “input panel”, and the compositor will move it for you.
   This means: when you’re using im module via dbus or typing in a Xwayland window with XIM, it can’t make use of this feature. But you may say, under plasma wayland, or gnome-shell I didn’t see any problem.This is because:
   – GNOME shell is the compositor, it can do hacky things to move the input method window around and make use of compositor feature. Currently gnome-shell’s ibus extension and https://github.com/wengxt/kimpanel-for-gnome-shell/ (you can use it with fcitx) use this method.
   – For Plasma, the plasma shell window occupies the whole screen, which makes kimpanel able to locate its window freely with absolute coordinates.Except these two specific environment (no, weston will not work), input method server will not be able to move the input method window freely.
4. Keyboard layout management
   This is somewhat less important for now, because of the issue listed above. Input method server (fcitx or ibus) are trying to managing keyboard layout, but there’s no common interface to do this.

Due to the issues above, I do not recommend to use wayland if you need input method. You can try it today, but you may find it working or not working. Also, these issues also largely extinguished my passion about working on wayland. Since for now there are still a lot of works going on with fcitx 5 and libime, my focus are mostly on them instead of making fcitx working on wayland.

But no need to give up too soon, as for the solution, It seems that KWin wants to run input method inside compositor process and this may solve a large portion of problem listed above, because: 1. kwin is compositor, it knows everything about a window, 2. kwin on wayland will control keyboard layout, 3. no “input-method” protocol is needed. Fcitx 5 also contains work to make fcitx run as a library more easily.

Right now my work replacing fcitx 4’s pinyin and table with libime is  near completion. Let’s see how it goes from here.