Inputting Localized Text

In the system environment, the VendorShell widget class is enhanced to provide the interface to the input method. While the VendorShell class controls only one child widget in its geometry management, an extension has been added to the VendorShell class to enhance it for managing all components necessary in the interface to an input method. These components include the status area, preedit area, and the MainWindow area.

When the input method requires a status area or a preedit area or both, the VendorShell widget automatically instantiates the status and preedit areas and manages their geometry layout. Any status area or preedit area is managed by the VendorShell widget internally and is not accessible by the client. The widget instantiated as the child of the VendorShell widget is called the MainWindow area.

The input method to be used by the VendorShell widget is determined by the XmNinputMethod resource; for example, @im=alt. The default value of Null indicates to choose the default input method associated with the locale at the time that VendorShell is created. As such, the user can affect which input method is selected by either setting the locale, setting the XmNinputMethod resource, or setting both. The locale name is concatenated with the XmNinputMethod resource to determine the input method name. The locale name must not be specified in this resource. The modifier name for the XmNinputMethod resource needs to be in the form @im=modifier, where modifier is the string used to qualify which input method is selected.

The VendorShell widget can support multiple widgets that can share the input method. Yet only one widget can have the keyboard focus (for example, receive key press events and send them to an input method) at any given time. To support multiple widgets (such as Text widgets), the widgets need to be descendants of the VendorShell widget.

The VendorShell widget class is a superclass of the TransientShell and TopLevelShell widget classes. As such, an instantiation of a TopLevelShell or a DialogShell is essentially an instantiation of a VendorShell widget class.

The VendorShell widget behaves as an input manager only if one of its descendants is an XmText[Field] instance. As soon as an XmText[Field] instance is created as a descendant of the VendorShell widget, VendorShell creates the necessary areas required by the particular input methods dictated by the current locale. Even if an XmText[Field] instance is not mapped but just created, VendorShell has the geometry management behavior as described previously.

A VendorShell widget does the following:

• Enables applications to process multibyte character input and output that is supported by the locales installed in the system.

• Manages an input method instance as defined in the XmIm reference functions.

• Supports preediting within a preedit area in either OffTheSpot, OverTheSpot, Root, or None mode. Localized text can be entered into any Text child widget in a multiple Text children widget tree by changing the focus.

• Provides geometry management for descendant child widgets.

Geometry Management

The VendorShell widget provides geometry management and focus management for the input method's user interface components, as necessary. If the locale warrants it (for example, if the locale is a Japanese Extended UNIX Code (EUC) locale), the VendorShell widget automatically allocates and manages the geometry of any required preedit area or status area or both.

Depending on the current preediting being done, an auxiliary area may be required. If so, the VendorShell widget also instantiates and manages the auxiliary area. Typically, the child of the VendorShell widget is a container widget (such as the XmBulletinBoard or XmRowColumn widgets) that can manage multiple Text and TextField widgets, which allow multibyte character input from the user. In this scenario, all Text widgets share the same input method.

The status, preedit, and auxiliary areas are not accessible to the application programmer. For example, it is not intended for the application programmer to access the window ID of the status area. The user does not need to worry about the instantiation or management of these components as they are managed as required by the VendorShell widget class.

The application programmer has some control over the behavior of the input method user interface components through XmNpreeditType resources of the VendorShell widget class. See "Input Methods" for a description of OffTheSpot and OverTheSpot modes.

Geometry management extends to all input method user interface components. When the application program window (a TopLevelShell widget) is resized, the input method user interface components are resized accordingly, and the preedited strings in them are rearranged as required. Of course, this assumes that the shell window has a resize policy of True.

When the VendorShell widget is created, if a specific input method requires a status area, preedit area, or both, the size of the VendorShell considers the areas required by these components. The extra areas required by the preedit and status areas are part of the VendorShell widget's area. They are also managed by the VendorShell widget, if resizing is necessary.

Because of the potential instantiation of these areas (status and preedit), depending on the input method currently being used, the size of the VendorShell widget area does not necessarily grow or shrink to accommodate exactly the size of its child. The size of the VendorShell widget area grows or shrinks to accommodate both its child's geometry and the geometry of these input method user interface areas. There may be a difference (for example, of 20 pixels) in height between the VendorShell widget and its child widget (the MainWindow area). The width geometry is not affected by the input method user interface components.

In summary, the requested size of the child is honored if possible; the actual size of the VendorShell may be larger than its child.

The requests to specify the geometry of the VendorShell widget and its child are honored as long as they do not conflict with each other or are within the constraint of the VendorShell widget's ability to resize. When they do conflict, the child's widget geometry request has higher precedence. For example, if the size of the child widget is specified as 100x100, the size of VendorShell is also specified as 100x100. The resulting VendorShell has a size of 100x120, while its child widget gets a size of 100x100. If the size of the child widget is not specified, the VendorShell shrinks its child widget if necessary to honor its own size specification. For example, if the size of VendorShell is specified as 100x100 and no size is specified for its child, the child widget has a size of 100x80. If the VendorShell widget is disabled from resizing, regardless of what the geometry request of its child is, the VendorShell widget honors only its own geometry specification.

Focus Management

Languages with large numbers of characters (such as Japanese and Chinese) require an input method that allows the user to compose characters in that language interactively. This is because, for these languages, there are many more characters than can be reasonably mapped to a terminal keyboard.

The interactive process of composing characters in such languages is called preediting. The preediting itself is handled by the input method. However, the user interface of the preediting is determined by the system environment. An interface needs to exist between the input method and the system environment. This is done through the VendorShell widget of the system environment.

Figure 4-3 illustrates a case with Japanese preediting. The string shown in reverse video is the string in preediting. This string can be moved across different windows by giving focus to the particular window. However, only one preediting session can occur at one time.

Figure 4-3 Japanese preediting example

For an example of focus management, suppose a TopLevelShell widget (a subclass of the VendorShell widget) has an XmBulletinBoard widget child (MainWindow area), which has five XmText widgets as children. Assume the locale requires the preedit area, and assume the OverTheSpot mode is specified. Because the VendorShell widget manages only one instance of an input method, you can run only one preedit area at a time inside the TopLevelShell widget. If the focus is moved from one Text widget to another, the current preedit string under construction is also moved on top of the Text widget that currently has focus. Processing of keys to the old Text widget is suspended temporarily. Subsequent interface of the input method, such as the delivery of the string at preedit completion, is made to the new, focused Text widget.

The string being preedited can be moved to the location of the focus; for example, by clicking the mouse.

A string that the end user is finished preediting and that is already confirmed cannot be reconverted. Once the string is composed, it is committed. Committing a string means that it is moved from the preedit area to the focus point of the client.