Jump to content United States-English
HP.com Home Products and Services Support and Drivers Solutions How to Buy
» Contact HP
More options
HP.com home
Common Desktop Environment: Internationalization Programmer's Guide > Chapter 1 Introduction to Internationalization

Input Methods

» 

Technical documentation

» Feedback
Content starts here

 » Table of Contents

 » Index

The Common Desktop Environment provides the ability to enter localized input for an internationalized application that is using the Motif Toolkit. Specifically, the XmText[Field] widgets are enabled to interface with input methods provided by each locale. In addition, the dtterm client is enabled to use input methods. For detailed information on input methods, refer to Motif Programmer's Guide.

By default, each internationalized client that uses the Motif Toolkit uses the input method associated with a locale specified by the user. The XmNinputMethod resource is provided as the input method portion of the locale modifiers to allow a user to specify any alternative input method.

The user interface of the input method consists of several elements. The need for these areas is dependent on the input method being used. They are usually needed by input methods that require complex input processing and dialogs. See Figure 1-3 for an illustration of these areas.

Figure 1-3 Example of VendorShell widget with auxiliary (Japanese)

Example of VendorShell widget with auxiliary (Japanese)

The VendorShell may contain the XmNinputPolicy resource. This dictates whether its children widgets share input contexts or not. When using a root window input method style, for example, the input context would probably be shared by several widgets, while in an off-the-spot input method style, the input context might be shared between more than one widget, although it might not. However, with an over-the-spot input method style, an input context would almost certainly belong to a single widget. The possible values of XmNinputPolicy are XmPER_WIDGET, which will provide a new input context for each widget, and XmPER_SHELL, which will cause the children widgets of a common shell to share a single input context.

Preedit Area

A preedit area is used to display the string being preedited. An input method can support the following modes of preediting: OffTheSpot, OnTheSpot (default) OverTheSpot, Root, and None.

NOTE: A string that has been committed cannot be reconverted. The status of the string is moved from the preedit area to the location where the user is entering characters.

OffTheSpot

In OffTheSpot mode preediting using an input method, the location of preediting is usually inside the application window on the right side of the status area as shown in Figure 1-4 “Example of OffTheSpot preediting with the VendorShell widget (Japanese)” A Japanese input method is used for the example.

Figure 1-4 Example of OffTheSpot preediting with the VendorShell widget (Japanese)

Example of OffTheSpot preediting with the VendorShell widget (Japanese)

When preediting using an input method, the preedit string being preedited may be highlighted in some form depending on the input method.

To use OffTheSpot mode, set the XmNpreeditType resource of the VendorShell widget either with the XtSetValues() function or with a resource file. The XmNpreeditType resource can also be set as the resource of a TopLevelShell, ApplicationShell, or DialogShell widget, all of which are subclasses of the VendorShell widget class.

OverTheSpot

In OverTheSpot mode, the location of the preedit area is set to where the user is trying to enter characters (for example, the insert cursor position of the Text widget that has the current focus). The characters in a preedit area are displayed at the cursor position as an overlay window, and they can be highlighted depending on the input method.

Although a preedit area may consist of multiple lines in OverTheSpot mode. The preedit area is always within the MainWindow area and cannot cross its edges in any direction.

Keep in mind that although the preedit string under construction may be displayed as though it were part of the Text widget's text, it is not passed to the client and displayed in the underlying edit screen until preedit ends. See Figure 1-5 “Example of OverTheSpot preediting with the VendorShell widget (Japanese)” for an illustration.

To use OverTheSpot mode explicitly, set the XmNpreeditType resource of the VendorShell widget either with the XtSetValues() function or with a resource file. The XmNpreeditType resource can be set as the resource of a TopLevelShell, ApplicationShell, or DialogShell widget because these are subclasses of the VendorShell widget class.

Figure 1-5 Example of OverTheSpot preediting with the VendorShell widget (Japanese)

Example of OverTheSpot preediting with the VendorShell widget (Japanese)

OnTheSpot (Default)

In OnTheSpot mode, the preedit string is displayed in the text widget window. The preedit string is considered part of the text widget value, and its integrity can be ensured by the verify callbacks of the text widget (the verify callbacks are controlled by the verifyPreedit resource, which defaults to False). If the verify callbacks of the text widget do not accept any part of the preedit buffer, the preedit string is committed (for information on user actions that cause the preedit string to be committed, refer to Motif Programmer's Guide).

When preediting using an input method, the preedit string being preedited may be highlighted in some form depending on the input method.

To use OnTheSpot mode, set the XmNpreeditType resource of the VendorShell widget either with the XtSetValues() function or with a resource file. The XmNpreeditType resource can also be set as the resource of a TopLevelShell, ApplicationShell, or DialogShell widget, all of which are subclasses of the VendorShell widget class.

Root

In Root mode, the preedit and status areas are located separate from the client's window. The Root mode behavior is similar to OffTheSpot. See Figure 1-6 “Example of Root preediting with the VendorShell widget (Japanese)” for an illustration.

Figure 1-6 Example of Root preediting with the VendorShell widget (Japanese)

Example of Root preediting with the VendorShell widget (Japanese)

Status Area

A status area reports the input or keyboard status of the input method to the users. For OverTheSpot and OffTheSpot styles, the status area is located at the lower left corner of the VendorShell window.

  • If Root style, the status area is placed outside the client window.

  • If the preedit style is OffTheSpot mode, the preedit area is displayed to the right of the status area.

The VendorShell widget provides geometry management so that a status area is rearranged at the bottom corner of the VendorShell window.

Auxiliary Area

An auxiliary area helps the user with preediting. Depending on the particular input method, an auxiliary area can be created. The Japanese input method in Figure 1-3 “Example of VendorShell widget with auxiliary (Japanese)” creates the following types of auxiliary areas:

  • ZENKOUHO

  • JIS NUMBER

  • Switching conversion method

    • SAKIYOMI-REN-BUNSETSU

    • IKKATSU-REN-BUNSETSU

    • TAN-BUNSETSU

    • FUKUGOU-GO

Focus Area

A focus area is any descendant widget under the VendorShell widget subtree that currently has focus. The Motif application programmer using existing widgets does not need to worry about the focus area. The important information to remember is that only one widget can have input method processing at a time. The input method processing moves to the window (widget) that currently has the focus.

Layout Direction

Layout direction refers to the direction that is used to display visual elements such as widget children, widget components, and text (controlled by the VendorShell resource, XmNlayoutDirection). In general, this direction matches the direction that people use when reading or writing in a particular language. Languages such as English, French, German, and Swedish are read and written from left to right. Therefore, when users working in those languages enter characters from a computer keyboard, each new character is displayed to the right of the preceding one. These same users would also expect the layout of other visual elements to be displayed from left to right. For example, in a menu bar, the cascade buttons would be laid out from left to right so that a simple menu bar would position the "File" cascade button in the upper left corner, and the "Help" cascade button would appear in the upper right corner of the menu bar.

Languages such as Arabic and Hebrew are read and written from right to left. To display text correctly in these languages on the screen, each successive character that a user enters must appear to the left of the preceding character. Using the example above for layout of other visual elements, these users would expect a menu bar to lay out cascade buttons from right to left. The result would typically position the "File" cascade button in the upper right corner and the "Help" cascade button in the upper left corner of the menu bar. For more information, on layout direction, refer to Motif Programmer's Guide.

Vertical Writing

In some Asian languages, texts are drawn vertically. When the VendorShell resource XmNlayoutDirection is set to XmTOP_TO_BOTTOM, the vertical writing feature is enabled. In addition to drawing texts vertically, this feature adapts the text widget in other ways appropriate for the user. For example, when word wrapping is turned on, the text wraps from the bottom of one column to the top of the next column. For more information on vertical writing, refer to Motif Programmer's Guide.

Printable version
Privacy statement Using this site means you accept its terms Feedback to webmaster
© Hewlett-Packard Development Company, L.P.