Next | Prev | Up | Top | Contents | Index
IM Styles
If the application requests it, an input method can often supply status information about itself. For example, a Japanese IM may be able to indicate whether it is in Japanese input mode or romaji input mode. An input method can also supply pre-edit information, partial feedback about characters in the process of being composed. The way an IM deals with status and pre-edit information is referred to as an IM style. This section describes styles and their naming.
Root Window
The Root Window style has a pre-edit area and a status area in a window owned by the IM as a descendant of the root. The application does not manage the pre-edit data, the pre-edit area, the status data, or the status area. Everything is left to the input method to do in its own window, as illustrated in Figure 6-1.
Figure 6-1 : Root Window Input
Off-the-Spot
The Off-the-Spot style places a pre-edit area and a status area in the window being used, usually in reserved space away from the place where input appears. The application manages the pre-edit area and status area, but allows the IM to update the data there. (The application provides information regarding foreground and background colors, fonts, and so on.) A window using Off-the-Spot input style might look like that shown in Figure 6-2.
Figure 6-2 : Off-the-Spot Input
Over-the-Spot
The Over-the-Spot style involves the IM creating a small, pre-edit window over the point of insertion. The window is owned and managed by the IM as a descendant of the root, but it gives the user the impression that input is being entered in the right place; in fact, the pre-edit window often has no borders and is invisible to the user, giving the appearance of On-the-Spot input. The application manages the status area as in Off-the-Spot, but specifies the location of the editing so that the IM can place pre-edit data over that spot.
On-the-Spot
On-the-Spot input is by far the most complex for the application developer. The IM delivers all pre-edit data via callbacks to the application, which must perform in-place editing--complete with insertion and deletion and so on. This approach usually involves a great deal of string and text rendering support at the input generation level, above and beyond the effort required for completed input. Since this may mean a lot of updating of surrounding data or other display management, everything is left to the application. There is little chance an IM could ever know enough about the application to be able to help it provide user feedback. The IM therefore provides status and edit information via callbacks.
Done well, this style can be the most intuitive one for a user.
Setting IM Styles
A style describes how an IM presents its pre-edit and status information to the user. An IM supplies information detailing its presentation capabilities. The information comes in the form of flags combined with OR. The flags to use with each style are as follows:
| Root Window | XIMPreeditNothing | XIMStatusNothing |
| Off-the-Spot | XIMPreeditArea | XIMStatusArea |
| Over-the-Spot | XIMPreeditPosition | XIMStatusArea |
| On-the-Spot | XIMPreeditCallbacks | XIMStatusCallbacks |
For example, if you wanted a style variable to match an Over-the-Spot IM style, you could write:
XIMStyle over = XIMPreeditPosition | XIMStatusArea;
If an IM returns XIMStatusNone (not to be confused with XIMStatusNothing), it means the IM will not supply status information.
Using Styles
An input method supports one or more styles. It's up to the application to find a style that is supported by both the IM and the application. If several exist, the application must choose. If none exist, the application is in trouble.
Next | Prev | Up | Top | Contents | Index