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
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
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
we used in the source code
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
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