Volume 6A: Motif Programming Manual

operates in that language without changes to the binary. An internationalized application must display all of its text in

the user's language and accept textual input in that same language. It must also display dates, times, and numbers in

the appropriate format for the language environment.

X internationalization is based on the ANSI−C internationalization model. This approach is based on the concept of

localization, whereby an application uses a library that reads a customizing database at startup time. This database

contains information about the characteristics of every locale that is supported by the system. When an application

establishes its locale by calling setlocale(), the library customizes the behavior of various routines based on the

locale. See the Third Edition of Volume One, Xlib Programming Manual, for a complete description of the concepts

and implementation of X internationalization.

Xt support of internationalization is trivial in most applications; the only additional code needed is a call to

XtSetLanguageProc() before the toolkit is initialized. XtSetLanguageProc() sets the language procedure

that is used to set the locale of an application. The first argument to the routine specifies an application context, the

second argument specifies the language procedure, and the third parameter specifies additional data that is passed to

the language procedure when it is called. Since the language procedure is responsible for setting the locale, an Xt

application does not call setlocale() directly. The language procedure is called by

XtDisplayInitialize().

If the second argument to XtSetLanguageProc() is NULL, the routine registers a default language procedure.

Here's the call that we used in the source code to set the default language procedure:

XtSetLanguageProc (NULL, NULL, NULL);

The default language procedure sets the locale according to the LANG environment variable, verifies that the current

locale is supported, and returns the value of the current locale. For more information about establishing the locale in

an Xt application, see Volume Four, X Toolkit Intrinsics Programming Manual.

Most of the support for internationalization in Motif 1.2 is provided by Xlib and Xt. Xlib provides support for

internationalized text output, interclient communication, and localization of the resource database, while Xt handles

establishing the locale. The Motif Text and TextField widgets have been modified to support internationalized text

input and output; see Section #stexti18n for more information. The Motif routines that work with compound strings

and font lists have also been updated in Motif 1.2. See Chapter 19, Compound Strings, for details on the new API for

XmString and XmFontList values.

3.3.3 Initializing the Toolkit

Before an application creates any widgets, it must initialize the toolkit. There are many ways to perform this task,

most of which also perform a number of related tasks, such as opening a connection to the X server and loading the

resource database. Here's a list of some of the things that are almost always done:

Open the application's connection to the X server.•

Parse the command line for the standard X Toolkit command−line options plus any custom command−line

options that have been defined for the application.

•

Create the resource database using the app−defaults file, if any, as well as any user, host, and locale−specific

resource files.

•

Create the application's top−level window, a Shell class widget that handles interaction with the window

manager and acts as the parent of all of the other widgets in the application.

•

There are several functions available to perform toolkit initialization. The one we use most often is

XtVaAppInitialize(), since it performs all of the functions listed above in one convenient call. Here's the call

3 The Motif Programming Model 3.3.3 Initializing the Toolkit

28

we used in the source code

Widget toplevel;

XtAppContext app;

toplevel = XtVaAppInitialize (&app, "Hello", NULL, 0,

&argc, argv, NULL, NULL);

The widget returned by XtVaAppInitialize() is a shell widget. The shell widget acts as the top−level window

of the application and handles the application's interaction with the window manager. All of the other widgets created

by the application are created as descendents of the shell, which we'll talk about more later in this chapter. The first

argument to XtVaAppInitialize() is the address of an application context, which is a structure that Xt uses to

manage some internal data associated with an application. Most applications do not manipulate the application context

directly. Most often, an application receives an opaque pointer to an application context in the toolkit initialization call

and merely passes that pointer to a few other toolkit functions that require it as an argument. The fact that the

application context is a public variable, rather than hidden in the toolkit internals, is a forward−looking feature of Xt,

designed to support multiple threads of control.

The simpler X11R3 initialization call, XtInitialize(), is still supported by later versions of the toolkit. Its use is

discouraged because the new initialization calls provide a greater degree of upward compatibility with future

Xt−based applications. The simpler function creates an application context that is stored internally by Xt. The second

argument to XtVaAppInitialize() is a string that defines the class name of the application. A class name is

used in resource files to specify resource values that apply to all instances of an application, a widget, or a resource.

(See Volume Three, X Window System User's Guide, Motif Edition, and Volume Four, X Toolkit Intrinsics

Programming Manual, for details.) For many applications, the application class is rarely used and the class name is

important only because it is also used as the name of the application's app−defaults file.

Whenever a widget is created in Xt, its resources must have certain initial (or default) values. You can either

hard−code the values, allow them to default to widget−defined values, or specify the default values in the

app−defaults file. These default values are used unless the user has provided his own default settings in another

resource file.

By convention, the class name is the same as the name of the application itself, except that the first letter is

capitalized. For example, a program named draw would have Some applications follow the convention that if the

application's name begins with an "X", the X is silent and so the second letter is capitalized as well. For example, the

class name of xterm is XTerm. a class name of Draw and an app−defaults filename of

/usr/lib/X11/app−defaults/Draw. Note, however, that there is no requirement that an app−defaults file with this name

actually be installed.

Exceptions can be made to this convention, as long as you document it. For example, all the example programs in this

book have the class name of Demos, which allows us to set certain common defaults in a single file. This technique

can be useful whenever you have a large collection of independent programs that are part of the same suite of

applications. The third and fourth arguments specify an array of objects that describe the command−line arguments for

your program, if any, and the number of arguments in the array. These arguments are unused in most of the examples

in this book and are specified as NULL and 0, respectively. The program xshowbitmap.c in the Appendix, Additional

Example Programs, provides an example of using command−line arguments. See Volume Four, X Toolkit Intrinsics

Programming Manual, for a more complete discussion of application−specific command−line arguments.

The fifth and sixth arguments contain the value (argv) and count (argc) of any actual command−line arguments.

The initialization call actually removes and acts on any arguments it recognizes, such as the standard X Toolkit

command−line options and any options that you have defined in the third argument. After this call, argv should

contain only the application name and any expected arguments such as filenames. You may want to check the

3 The Motif Programming Model 3.3.3 Initializing the Toolkit

29