Window Object Layout

Window objects include push-pins, popup menus, control buttons, and scrollbars. Layout of objects containing strings (such as menus and buttons) can change because the dimensions of those strings often change when switching languages. For example, a control button in English is probably shorter than the equivalent in German. Also, a control button in Japanese is probably taller than the equivalent in English. Even in the same language, control buttons can grow and overlap when the font size increases. In XView, here's how you would determine the length and height of a text string:

The dims structure now contains the string's width as its first element, and the string's height as its second element.

XView application layout may be implicit or explicit. Implicit layout relies on the toolkit to position objects. Explicit layout means that the programmer specifies pixel values (or row and column values) both for position (x, y) and dimension (width, height, and gaps).

If you create a series of controls without specifying location information, the toolkit will position items based on its built-in spacing rules. Implicit layout will very likely make localization easier, since control objects will often be repositioned for you as required. So if you have time, try using implicit layout whenever possible. DeskSet 3.3 tools use a custom library for implicit layout.

The XView toolkit provides a limited implicit layout facility. Basically, control area objects such as buttons are positioned based on default spacing rules. However, if button width increases so that the right-most button is outside the control area, the toolkit wraps that button to the next line, rather than expanding the control area. DeskSet 3.3 tools such as Mail Tool and Calendar Manager re-layout gracefully because developers have added code to properly center and size objects, based on current window size as well as font size.

Object Size and Positioning

International XView contains attributes to allow run time configuration of the size and position of objects making up an application's interface. Size and positioning information is retrieved from an Xwindows-style resource database. The attributes associated with sizing and positioning objects are:

XV_INSTANCE_NAME
  Provides a mechanism to give each XView object a unique name, so that it
  can be queried from the database.

XV_USE_DB Allows you to specify a null-terminated list of attributes value pairs. Each attribute's value will be looked up in the database; if not found, the specified value is used as the default.

XV_LOCALE_DIR An xv_init() attribute, tells XView where the app-defaults directory is located. The resource database file resides in a directory called app-defaults. Like the scheme used by the message object files, the parent of the app-defaults directory is the name of the locale. The name of the resource database file is the name of the application with a .db suffix appended to it.

To illustrate the use of these attributes, see how the following portion of code from the file my_app.c is modified:

Assuming the resource database (.db) file for the Spanish locale resides in /home/locale/spanish/app-defaults, here's how to modify the code:

When the application runs, it builds a path using the directory pointed to by XV_LOCALE_DIR, the name of the current locale, and app-defaults. This path is used to search for the resource database (.db) file. Any attribute specified in the XV_USE_DB attribute list, whose parent is given a name with XV_INSTANCE_NAME, will have its valued looked up in the file. If the attribute is found, the value in the database is used; if the attribute isn't found, the value specified in the source code is used.

For the example above, the entries in the resource database file my_app.db would look like this:

If the layout has changed for a specific locale, an interface object may need to be repositioned. For example, let's say that for the Spanish locale, the interface looks more presentable if the above button is positioned at position 20,11 rather than position 10,10. All the developer needs to do is to change the x and y values in the .db file and rerun the application (without recompiling!). In this case, the above database lines would be changed to:

The button would then appear at position 20,11.

Input Method

Phonetic-based languages such as English are easy to type on a keyboard. However, typing is much more complicated for East Asian languages based on ideograms. When entering Japanese, for example, the typist must select between Kanji, Hiragana, Katakana, and Romaji (Roman letters used phonetically to produce Japanese words). There must also be a way to convert phonetic characters into Kanji. Input is further complicated because a given syllable can frequently be represented by several different Kanji characters--the user must select the Kanji character that is appropriate for the specific context. Here's how you'd type Japanese under OpenWindows with a Japanese keyboard.

1. Set the LANG environment to Japanese.

2. The initial input mode simulates a Type-4 or a PC-AT101 US keyboard. To switch input modes, press the Nihongo (Japanese) key.

3. Type words using phonetic values in Romaji, or press the Romaji/Kana toggle key and type words in Hiragana. Japanese engineers often prefer typing in Romaji, but most clerks prefer Hiragana since it requires fewer keystrokes. With either method, the system echoes Hiragana letters in reverse video.

4. If that Hiragana word is the one you want, press the Commit key.

5. To convert the word to Kanji, press the Conversion key. The system shows a Kanji spelling in the Pre-edit Region. If that's the spelling you want, press the Commit key. If not, press the Conversion key again to see the next choice.

Font Handling

In OpenWindows 3.3, all 56 OpenFonts^(R) in all sizes include ISO Latin-1 characters. Most other OpenWindows fonts do not.

Solaris supports EUC encoding, as did releases of Asian OpenWindows. Refer to Chapter 3 for more information on EUC. To support languages with multiple character fonts, XView applications can open a font set. Here's an example of a call to open the Minchou font with Internationalized XView. This is intended only as an example--the actual interface for Japanese and Asian OpenWindows might be different:

Additionally, there are two new text functions to handle wide characters: XwcDrawString is the wide character equivalent of XDrawString, and XwcTextWidth is the wide character equivalent of XTextWidth.

---

Note - Earlier releases of OpenWindows displayed ISO Latin-1 characters by default, even if the LC_CTYPE environment variable was not set. Because this release of OpenWindows supports multibyte characters and EUC, Latin-1 characters are not displayed unless the LC_CTYPE environment variable is set to iso_8859_1.

---