DocsWithin the X Window System environment, the following two typical architectural models can be used as an input method's implementation model.
- Client/Server model: | A separate process, the IM Server, processes input and handles preediting, converting, and committing. The IM library within the application, acting as client to the IM Server, simply receives the committed string from the IM Server. |
- Library model: | All input is handled by the IM library within the application. The event process is closed within the IM library and a separate IM Server process may not be required. |
Most languages which need complex preediting, such as Asian languages, are implemented using the Client/Server IM model. Other languages which need only dead key or compose key processing, such as European languages, are implemented using the Library model.
In this paper, we discuss mainly the Client/Server IM model and the protocol used in communication between the IM library (client) and the IM Server.
When the client connects or disconnects to the IM Server, an open or close operation occurs between the client and the IM Server.
The IM can be specified at the time of XOpenIM() by setting the locale of the client and a locale modifier. Since the IM remembers the locale at the time of creation XOpenIM() can be called multiple times (with the setting for the locale and the locale modifier changed) to support multiple languages.
In addition, the supported IM type can be obtained using XGetIMValues().
The client usually holds multiple input (text) fields. Xlib provides a value type called the "Input Context" (IC) to manage each individual input field. An IC can be created by specifying XIM using XCreateIC(), and it can be destroyed using XDestroyIC().
The IC can specify the type of IM which is supported by XIM for each input field, so each input field can handle a different type of IM.
Most importantly information such as the committed string sent from the IM Server to the client, is exchanged based on each IC.
Since each IC corresponds to an input field, the focused input field should be announced to the IM Server using XSetICFocus(). (XUnsetICFocus() can also be used to change the focus.)
Existing input methods support either the FrontEnd method, the BackEnd method, or both. This protocol specifically supports the BackEnd method as the default method, but also supports the FrontEnd method as an optional IM Server extension.
The difference between the FrontEnd and BackEnd methods is in how events are delivered to the IM Server. (Fig. 1)
In the BackEnd method, client window input events are always delivered to the IM library, which then passes them to the IM Server. Events are handled serially in the order delivered, and therefore there is no synchronization problem between the IM library and the IM Server.
Using this method, the IM library forwards all KeyPress and KeyRelease events to the IM Server (as required by the Event Flow Control model described in Event Flow Control) and synchronizes with the IM Server (as described in Filtering Events).
In the FrontEnd method, client window input events are delivered by the X server directly to both the IM Server and the IM library. Therefore this method provides much better interactive performance while preediting (particularly in cases such as when the IM Server is running locally on the user's workstation and the client application is running on another workstation over a relatively slow network).
However, the FrontEnd model may have synchronization problems between the key events handled in the IM Server and other events handled in the client, and these problems could possibly cause the loss or duplication of key events. For this reason, the BackEnd method is the core method supported, and the FrontEnd method is made available as an extension for performance purposes. (Refer to Common Extensions for more information.)
This protocol supports two event flow models for communication between the IM library and the IM Server (Static and Dynamic).
Static Event Flow requires that input events always be sent to the IM Server from the client.
Dynamic Event Flow, however, requires only that those input events which need to be processed (converted) be sent to the IM Server from the client.
For instance, in the case of inputing a combination of ASCII characters and Chinese characters, ASCII characters do not need to be processed in the IM Server, so their key events do not have to be sent to the IM Server. On the other hand, key events necessary for composing Chinese characters must be sent to the IM Server.
Thus, by adopting the Dynamic Event Flow, the number of requests among the
X Server, the client, and the IM Server is significantly reduced, and the
number of context switches is also reduced, resulting in improved performance.
The IM Server can send
XIM_REGISTER_TRIGGERKEYS
message in order to switch the event flow in the Dynamic Event Flow.
The protocol for this process is described in Event Flow Control.