How does an application talk to Fcitx

This article is intended to explain some histories and underlying details about how Fcitx works from an application point of view, and answers some question about why sometimes an application does not work.

The relationship between an application and Fcitx basically follows Client-server model. An applications may act as one or more clients to Fcitx. Every "Client" is called an "Input context" from Fcitx point of view. Fcitx and the application need to use some way to talk to each other. In Fcitx 5, the addon category that is responsible to the communication to application are called "frontend".

X11

There is a generic input method protocol implemented with X, call X Input method. The most common used implementation of this protocol is within Xlib.

The latest version of this protocol was written in 90s. The protocol itself is old, and the implementation in Xlib is even worse.

The usability issue of XIM drives Linux input method developer to create their own "protocols", which leads to a solution usually referred as "IM module".

Gtk/Qt

IM module itself is just a plugin system uses by two most commonly used toolkit Gtk/Qt. The plugin system allows user to load a shared library (in most common case), or link a static plugin (if Qt itself is statically linked) to produce the functionality of input method.

Fcitx uses this plugin system to implement a D-Bus based protocol to talk to Fcitx's dbus frontend.

Gtk2, Gtk3, and Qt4 also ship an IM module that implements XIM. When Qt5 migrates from Xlib to XCB as the library to implement X11 integration, it loses the XIM support. Because at that time, there is no XCB based implementation of XIM. Gtk4 removes XIM support because its considered it as deprecated.

Usually, there are multiple IM module plugins installed on the system. If the relevant environment variable is not set, it will follow some logic in the toolkit to pick up one. To ensure the right IM module is picked by application, there are some environment variables can be used to enforce the desired IM module.

Also, since sandbox-based applications like flatpak are become more and more popular today, it actually requires the sandboxed application to bundle the IM module with their application. Fcitx team already makes the most commonly used flatpak runtimes (org.freedesktop.Sdk, org.gnome.Sdk, org.kde.Sdk) to bundle the im modules.

Fcitx 5 also supports fcitx 4's dbus protocol and IBus's dbus protocol.

SDL

SDL1 supports XIM. SDL2 has a similar issue like Qt5 and it loses XIM SDL does not provide a shared library based plugin system like Gtk or Qt, but SDL2 also bundles Fcitx support within it and can be enforced with SDL_IM_MODULE=fcitx.

Wayland

There are several version of text-input protocol on wayland and being used by different toolkits and applications. This page describes the current situation.

Some random applications

kitty

kitty uses IBus protocol on X11 if GLFW_IM_MODULE is set to ibus.

Emacs

Emacs usually uses Gtk as its toolkit on Linux, but it's input method is using XIM with its own Xlib code. Latest Emacs that uses pure Gtk branch may use Gtk IM module framework as its input method implementation.

Chrome/Chromium/Electron

On X11 its using Gtk im module like regular Gtk application. On wayland, check this section for more details.