app.widget.translations: value
to
app.widget.baseTranslations: value
If it is important to the application to preserve complete
compatibility of the defaults file between different versions
of the application running under Release 4 and Release 5,
the full translations can be replicated in both the “translations”
and the “baseTranslations” resource.
### Resource File Search Path
The current specification allows implementations greater flexibility
in defining the directory structure used to hold the application class
and per-user application defaults files. Previous specifications
required the substitution strings to appear in the default path in a
certain order, preventing sites from collecting all the files for
a specific application together in one directory. The Release 5
specification allows the default path to specify the substitution
strings in any order within a single path entry. Users will need to
pay close attention to the documentation for the specific
implementation to know where to find these files and how to specify
their own
*XFILESEARCHPATH*
and
*XUSERFILESEARCHPATH*
values when overriding the system defaults.
### Customization Resource
*XtResolvePathname*
supports a new substitution string, %C, for specifying separate
application class resource files according to arbitrary user-specified
categories. The primary motivation for this addition was separate
monochrome and color application class defaults files. The
substitution value is obtained by querying the current resource
database for the application resource name “customization”, class
“Customization”. Any application that previously used this
resource name and class will need to be aware of the possibly
conflicting semantics.
### Per-Screen Resource Database
To allow a user to specify separate preferences for each screen of a
display, a per-screen resource specification string has been added and
multiple resource databases are created; one for each screen. This
will affect any application that modified the (formerly unique)
resource database associated with the display subsequent to the Intrinsics
database initialization. Such applications will need to be aware
of the particular screen on which each shell widget is to be created.
Although the wording of the specification changed substantially in the
description of the process by which the resource database(s) is
initialized, the net effect is the same as in prior releases with the
exception of the added per-screen resource specification and the new
customization substitution string in
*XtResolvePathname*.
### Internationalization of Applications
Internationalization as defined by ANSI is a technology that
allows support of an application in a single locale. In
adding support for internationalization to the Intrinsics
the restrictions of this model have been followed.
In particular, the new Intrinsics interfaces are designed to not
preclude an application from using other alternatives.
For this reason, no Intrinsics routine makes a call to establish the
locale. However, a convenience routine to establish the
locale at initialize time has been provided, in the form
of a default procedure that must be explicitly installed
if the application desires ANSI C locale behavior.
As many objects in X, particularly resource databases, now inherit
the global locale when they are created, applications wishing to use
the ANSI C locale model should use the new function
*XtSetLanguageProc*
to do so.
The internationalization additions also define event filters
as a part of the Xlib Input Method specifications. The
Intrinsics enable the use of event filters through additions to
*XtDispatchEvent*.
Applications that may not be dispatching all events through
*XtDispatchEvent*
should be reviewed in the context of this new input method mechanism.
In order to permit internationalization of error messages the name
and path of the error database file is now allowed to be implementation
dependent. No adequate standard mechanism has yet been suggested to
allow the Intrinsics to locate the database from localization information
supplied by the client.
The previous specification for the syntax of the language string
specified by
*xnlLanguage*
has been dropped to avoid potential conflicts with other standards.
The language string syntax is now implementation-defined.
The example syntax cited is consistent with the previous
specification.
### Permanently Allocated Strings
In order to permit additional memory savings, an Xlib interface was
added to allow the resource manager to avoid copying certain string
constants. The Intrinsics specification was updated to explicitly require
the Object class_name, resource_name, resource_class,
resource_type, default_type in resource tables, Core actions
string field, and Constraint resource_name, resource_class,
resource_type, and default_type resource fields to be
permanently allocated. This explicit requirement is expected to
affect only applications that may create and destroy classes
on the fly.
### Arguments to Existing Functions
The args argument to
*XtAppInitialize*,
*XtVaAppInitialize*,
*XtOpenDisplay*,
*XtDisplayInitialize*,
and
*XtInitialize*
were changed from
*Cardinal\**
to int\* to conform to pre-existing convention and avoid otherwise
annoying typecasting in ANSI C environments.
### Implementation
Function prototypes are now fully supported in the header files.
`Copyright © 1991 by the Massachusetts Institute of Technology .
Permission to use, copy, modify, and distribute this document for any purpose and without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies, and that the name of MIT not be used in advertising or publicity pertaining to this document without specific, written prior permission. MIT makes no representations about the suitability of this document for any purpose. It is provided “as is” without express or implied warranty.