Move Xt specs from xorg-docs module

For now, just checked in and included in dist tarballs, not processed
into a usable format - same as it was in xorg-docs

Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>

1 files changed, 805 insertions, 0 deletions

diff --git a/specs/CH13 b/specs/CH13
new file mode 100644
index 0000000..8c944a6
--- /dev/null
+++ b/specs/CH13
@@ -0,0 +1,805 @@
+.\" $Xorg: CH13,v 1.3 2000/08/17 19:42:47 cpqbld Exp $
+.\" Copyright \(co 1985, 1986, 1987, 1988, 1991, 1994
+.\" X Consortium
+.\" 
+.\" Permission is hereby granted, free of charge, to any person obtaining
+.\" a copy of this software and associated documentation files (the
+.\" "Software"), to deal in the Software without restriction, including
+.\" without limitation the rights to use, copy, modify, merge, publish,
+.\" distribute, sublicense, and/or sell copies of the Software, and to
+.\" permit persons to whom the Software is furnished to do so, subject to
+.\" the following conditions:
+.\" 
+.\" The above copyright notice and this permission notice shall be included
+.\" in all copies or substantial portions of the Software.
+.\" 
+.\" THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+.\" OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+.\" MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
+.\" IN NO EVENT SHALL THE X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR
+.\" OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+.\" ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+.\" OTHER DEALINGS IN THE SOFTWARE.
+.\" 
+.\" Except as contained in this notice, the name of the X Consortium shall
+.\" not be used in advertising or otherwise to promote the sale, use or
+.\" other dealings in this Software without prior written authorization
+.\" from the X Consortium.
+.\" 
+.\" Copyright \(co 1985, 1986, 1987, 1988, 1991, 1994
+.\" Digital Equipment Corporation, Maynard, Massachusetts.
+.\" 
+.\" Permission to use, copy, modify and distribute this documentation for any
+.\" purpose and without fee is hereby granted, provided that the above copyright
+.\" notice appears in all copies and that both that copyright notice and this
+.\" permission notice appear in supporting documentation, and that the name of
+.\" Digital not be used in in advertising or publicity pertaining
+.\" to distribution of the software without specific, written prior permission.
+.\" Digital makes no representations about the suitability of the
+.\" software described herein for any purpose.
+.\" It is provided ``as is'' without express or implied warranty.
+.\"
+\&
+.sp 1
+.ce 3
+\s+1\fBChapter 13\fP\s-1
+
+\s+1\fBEvolution of the \*(xI\fP\s-1
+.sp 2
+.nr H1 13
+.nr H2 0
+.nr H3 0
+.nr H4 0
+.nr H5 0
+.LP
+.XS
+Chapter 13 \(em Evolution of the \*(xI
+.XE
+.LP
+The interfaces described by this specification have undergone several
+sets of revisions in the course of adoption as an X Consortium
+standard specification.  Having now been adopted by the Consortium as
+a standard part of the X Window System, it is expected that this and
+future revisions will retain
+backward compatibility in the sense that fully conforming
+implementations of these specifications may be produced that provide
+source compatibility with widgets and applications written to
+previous Consortium standard revisions.
+.LP
+The \*(xI do not place any special requirement on widget
+programmers to retain source or binary compatibility for their widgets
+as they evolve, but several conventions have been established to
+assist those developers who want to provide such compatibility.
+.LP
+In particular, widget programmers may wish to conform to the convention
+described in Section 1.6.12 when defining class extension records.
+
+.NH 2
+Determining Specification Revision Level
+.XS
+\fB\*(SN Determining Specification Revision Level\fP
+.XE
+.LP
+Widget and application developers who wish to maintain a common source
+pool that will build properly with implementations of the \*(xI
+at different revision levels of these specifications but that take
+advantage of newer features added in later revisions may use the
+symbolic macro
+.PN XtSpecificationRelease .
+.LP
+.Ds 0
+#define XtSpecificationRelease 6
+.De
+.IN "XtSpecificationRelease" "" "@DEF@"
+.LP
+As the symbol
+.PN XtSpecificationRelease
+was new to Release 4, widgets and
+applications desiring to build against earlier implementations should
+test for the presence of this symbol and assume only Release 3
+interfaces if the definition is not present.
+
+.NH 2
+Release 3 to Release 4 Compatibility
+.XS
+\fB\*(SN Release 3 to Release 4 Compatibility\fP
+.XE
+.LP
+At the data structure level, Release 4 retains binary compatibility
+with Release 3 (the first X Consortium standard release) for all data
+structures except
+.PN WMShellPart, 
+.PN TopLevelShellPart ,
+and
+.PN TransientShellPart .
+Release 4 changed the argument type to most procedures that now take
+arguments of type
+.PN XtPointer
+and structure members that are now of type
+.PN XtPointer
+in order to avoid potential ANSI C conformance problems.  It is
+expected that most implementations will be binary compatible with the
+previous definition.
+.LP
+Two fields in
+.PN CoreClassPart
+were changed from
+.PN Boolean
+to
+.PN XtEnum
+to allow implementations additional freedom in specifying the
+representations of each.  This change should require no source
+modification.
+
+.NH 3
+Additional Arguments
+.XS
+\*(SN Additional Arguments
+.XE
+.LP
+Arguments were added to the procedure definitions for
+.PN XtInitProc ,
+.PN XtSetValuesFunc ,
+and
+.PN XtEventHandler
+to provide more information and to
+allow event handlers to abort further dispatching of the current event
+(caution is advised!).  The added arguments to
+.PN XtInitProc
+and
+.PN XtSetValuesFunc
+make the initialize_hook and set_values_hook methods
+obsolete, but the hooks have been retained for those widgets that used
+them in Release 3.
+
+.NH 3
+set_values_almost Procedures
+.XS
+\*(SN set_values_almost Procedures
+.XE
+.LP
+The use of the arguments by a set_values_almost procedure was poorly
+described in Release 3 and was inconsistent with other conventions.
+.LP
+The current specification for the manner in which a set_values_almost
+procedure returns information to the \*(xI is not compatible with
+the Release 3 specification, and all widget implementations should
+verify that any set_values_almost procedures conform to the current
+interface.
+.LP
+No known implementation of the \*(xI correctly implemented the
+Release 3 interface, so it is expected that the impact of this
+specification change is small.
+
+.NH 3
+Query Geometry
+.XS
+\*(SN Query Geometry
+.XE
+.LP
+A composite widget layout routine that calls
+.PN XtQueryGeometry
+is now expected to store the complete new geometry in the intended structure;
+previously the specification said ``store the changes it intends to
+make''.  Only by storing the complete geometry does the child have
+any way to know what other parts of the geometry may still be
+flexible.  Existing widgets should not be affected by this, except
+to take advantage of the new information.
+
+.NH 3
+unrealizeCallback Callback List
+.XS
+\*(SN unrealizeCallback Callback List
+.XE
+.LP
+In order to provide a mechanism for widgets to be notified when they
+become unrealized through a call to
+.PN XtUnrealizeWidget ,
+the callback
+list name ``unrealizeCallback'' has been defined by the \*(xI.  A
+widget class that requires notification on unrealize may declare a
+callback list resource by this name.  No class is required to declare
+this resource, but any class that did so in a prior revision may find
+it necessary to modify the resource name if it does not wish to use the new
+semantics.
+
+.NH 3
+Subclasses of WMShell
+.XS
+\*(SN Subclasses of WMShell
+.XE
+.LP
+The formal adoption of the \fI\*(xC\fP as
+an X Consortium standard has meant the addition of four fields to
+.PN WMShellPart
+and one field to
+.PN TopLevelShellPart .
+In deference to some
+widget libraries that had developed their own additional conventions
+to provide binary compatibility, these five new fields were added at
+the end of the respective data structures. 
+.LP
+To provide more convenience for TransientShells, a field was added
+to the previously empty
+.PN TransientShellPart .
+On some architectures the size of the part structure will not
+have changed as a result of this.
+.LP
+Any widget implementation whose class is a subclass of
+TopLevelShell
+or
+TransientShell
+must at minimum be
+recompiled with the new data structure declarations.  Because
+.PN WMShellPart
+no longer contains a contiguous
+.PN XSizeHints
+data structure,
+a subclass that expected to do a single structure assignment of an
+.PN XSizeHints
+structure to the \fIsize_hints\fP field of
+.PN WMShellPart
+must be revised, though the old fields remain at the same positions within
+.PN WMShellPart .
+
+.NH 3
+Resource Type Converters
+.XS
+\*(SN Resource Type Converters
+.XE
+.LP
+A new interface declaration for resource type converters was defined
+to provide more information to converters, to support conversion
+cache cleanup with resource reference counting, and to allow
+additional procedures to be declared to free resources.  The old
+interfaces remain (in the compatibility section), and a new set of
+procedures was defined that work only with the new type converter
+interface.
+.LP
+In the now obsolete old type converter interface, converters are
+reminded that they must return the size of the converted value as well
+as its address.  The example indicated this, but the description of
+.PN XtConverter
+was incomplete.
+
+.NH 3
+KeySym Case Conversion Procedure
+.XS
+\*(SN KeySym Case Conversion Procedure
+.XE
+.LP
+The specification for the
+.PN XtCaseProc
+function type has been changed
+to match the Release 3 implementation, which included necessary
+additional information required by the function (a pointer to the
+display connection), and corrects the argument type of the source
+KeySym parameter.  No known implementation of the \*(xI
+implemented the previously documented interface.
+
+.NH 3
+Nonwidget Objects
+.XS
+\*(SN Nonwidget Objects
+.XE
+.LP
+Formal support for nonwidget objects is new to Release 4.  A
+prototype implementation was latent in at least one Release 3
+implementation of the \*(xI, but the specification has changed
+somewhat.  The most significant change is the requirement for a
+composite widget to declare the
+.PN CompositeClassExtension
+record with the \fIaccepts_objects\fP field set to
+.PN True
+in order to permit a client to create a nonwidget child.
+.LP
+The addition of this extension field ensures that composite widgets
+written under Release 3 will not encounter unexpected errors if an
+application attempts to create a nonwidget child.  In Release 4 there
+is no requirement that all composite widgets implement the extra
+functionality required to manage windowless children, so the
+\fIaccepts_objects\fP field allows a composite widget to declare that it
+is not prepared to do so.
+
+.NH 2
+Release 4 to Release 5 Compatibility
+.XS
+\fB\*(SN Release 4 to Release 5 Compatibility\fP
+.XE
+.LP
+At the data structure level, Release 5 retains complete binary
+compatibility with Release 4.  The specification of the
+.PN ObjectPart ,
+.PN RectObjPart ,
+.PN CorePart ,
+.PN CompositePart ,
+.PN ShellPart ,
+.PN WMShellPart ,
+.PN TopLevelShellPart ,
+and
+.PN ApplicationShellPart
+instance records was made less strict to permit implementations to
+add internal fields to these structures.  Any implementation that
+chooses to do so would, of course, force a recompilation.
+The Xlib specification for
+.PN XrmValue
+and
+.PN XrmOptionDescRec
+was updated to use a new type,
+.PN XPointer ,
+for the \fIaddr\fP and \fIvalue\fP fields, respectively, to avoid
+ANSI C conformance problems.  The definition of
+.PN XPointer
+is binary compatible with the previous implementation.
+
+.NH 3
+baseTranslations Resource
+.XS
+\fB\*(SN baseTranslations Resource\fP
+.XE
+
+.LP
+A new pseudo-resource, XtNbaseTranslations, was defined to permit
+application developers to specify translation tables in application
+defaults files while still giving end users the ability to augment
+or override individual event sequences.  This change will affect
+only those applications that wish to take advantage of the new
+functionality or those widgets that may have previously defined
+a resource named ``baseTranslations''.
+.LP
+Applications wishing to take advantage of the new functionality
+would change their application defaults file, e.g., from
+.Ds
+	app.widget.translations: \fIvalue\fP
+.DE
+to
+.Ds
+	app.widget.baseTranslations: \fIvalue\fP
+.DE
+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.
+
+.NH 3
+Resource File Search Path
+.XS
+\fB\*(SN Resource File Search Path\fP
+.XE
+
+.LP
+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
+.PN \s-1XFILESEARCHPATH\s+1
+and
+.PN \s-1XUSERFILESEARCHPATH\s+1
+values when overriding the system defaults.
+
+.NH 3
+Customization Resource
+.XS
+\fB\*(SN Customization Resource\fP
+.XE
+
+.LP
+.PN 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.
+
+.NH 3
+Per-Screen Resource Database
+.XS
+\fB\*(SN Per-Screen Resource Database\fP
+.XE
+
+.LP
+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 \*(xI
+database initialization.  Such applications will need to be aware
+of the particular screen on which each shell widget is to be created.
+.LP
+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
+.PN XtResolvePathname .
+
+.NH 3
+Internationalization of Applications
+.XS
+\fB\*(SN Internationalization of Applications\fP
+.XE
+
+.LP
+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 \*(xI
+the restrictions of this model have been followed.
+In particular, the new \*(xI interfaces are designed not to
+preclude an application from using other alternatives.
+For this reason, no \*(xI 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.
+.LP
+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
+.PN XtSetLanguageProc
+to do so.
+.LP
+The internationalization additions also define event filters
+as a part of the Xlib Input Method specifications.  The
+\*(xI enable the use of event filters through additions to
+.PN XtDispatchEvent .
+Applications that may not be dispatching all events through
+.PN XtDispatchEvent
+should be reviewed in the context of this new input method mechanism.
+.LP
+In order to permit internationalization of error messages, the name
+and path of the error database file are now allowed to be
+implementation-dependent.
+No adequate standard mechanism has yet been suggested to
+allow the \*(xI to locate the database from localization information
+supplied by the client.
+.LP
+The previous specification for the syntax of the language string
+specified by
+.PN 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.
+
+.NH 3
+Permanently Allocated Strings
+.XS
+\*(SN Permanently Allocated Strings
+.XE
+
+.LP
+In order to permit additional memory savings, an Xlib interface was
+added to allow the resource manager to avoid copying certain string
+constants.  The \*(xI specification was updated to explicitly require
+the Object \fIclass_name\fP, \fIresource_name\fP, \fIresource_class\fP,
+\fIresource_type\fP, \fIdefault_type\fP in resource tables, Core \fIactions\fP
+\fIstring\fP field, and Constraint \fIresource_name\fP, \fIresource_class\fP,
+\fIresource_type\fP, and \fIdefault_type\fP resource fields to be
+permanently allocated.  This explicit requirement is expected to
+affect only applications that may create and destroy classes
+on the fly.
+
+.NH 3
+Arguments to Existing Functions
+.XS
+\fB\*(SN Arguments to Existing Functions\fP
+.XE
+
+.LP
+The \fIargs\fP argument to
+.PN XtAppInitialize ,
+.PN XtVaAppInitialize ,
+.PN XtOpenDisplay ,
+.PN XtDisplayInitialize ,
+and
+.PN XtInitialize
+were changed from
+.PN Cardinal *
+to int* to conform to pre-existing convention and avoid otherwise
+annoying typecasting in ANSI C environments.
+
+.NH 2
+Release 5 to Release 6 Compatibility
+.XS
+\fB\*(SN Release 5 to Release 6 Compatibility\fP
+.XE
+.LP
+At the data structure level, Release 6 retains binary compatibility
+with Release 5 for all data structures except 
+.PN WMShellPart .
+Three resources were added to the specification.  
+The known implementations had unused space in the data structure,
+therefore on some architectures and implementations,
+the size of the part structure will not have changed as a result of this.
+
+.NH 3
+Widget Internals
+.XS
+\*(SN Widget Internals
+.XE
+.LP
+Two new widget methods for instance allocation and deallocation were added
+to the Object class.  These new methods 
+allow widgets to be treated as C++ objects in the C++ environment
+when an appropriate allocation method is specified or inherited 
+by the widget class.
+.LP
+The textual descriptions of the processes of widget creation and
+widget destruction have been edited to provide clarification to widget
+writers.  Widgets writers may have reason to rely on the specific order of 
+the stages of widget creation and destruction; with that motivation,
+the specification now more exactly describes the process.
+.LP
+As a convenience, an interface to locate a widget class extension
+record on a linked list, 
+.PN XtGetClassExtension ,
+has been added.
+.LP
+A new option to allow bundled changes to the managed set of a Composite
+widget is introduced in the Composite class extension record.
+Widgets that define a change_managed procedure that can accommodate
+additions and deletions to the managed set of children in a single
+invocation should set allows_change_managed_set to \fBTrue\fP in the
+extension record.
+.LP
+The wording of the process followed by
+.PN XtUnmanageChildren
+has changed slightly to better handle changes to the managed set
+during phase 2 destroy processing.
+.LP
+A new exposure event compression flag,
+.PN XtExposeNoRegion ,
+was added.  Many widgets specify exposure compression, but either
+ignore the actual damage region passed to the core expose procedure or
+use only the cumulative bounding box data available in the event.
+Widgets with expose procedures that do not make use of exact
+exposure region information can indicate that the \*(xI need not
+compute the region.
+
+.NH 3
+General Application Development
+.XS
+\*(SN General Application Development
+.XE
+.LP
+.PN XtOpenApplication
+is a new convenience procedure to initialize the toolkit, create an
+application context, open an X display connection, and create the
+root of the widget instance tree.  It is identical to the interface
+it replaces, 
+.PN XtAppInitialize ,
+in all respects except that it takes an additional argument specifying
+the widget class of the root shell to create.
+This interface is now the recommended one so that clients may easily
+become session participants.
+The old convenience procedures appear in the compatibility section.
+.LP
+The toolkit initialization function
+.PN XtToolkitInitialize
+may be called multiple times without penalty.
+.LP
+In order to optimize changes in geometry to a set of geometry-managed
+children, a new interface,
+.PN XtChangeManagedSet ,
+has been added.
+
+.NH 3
+Communication with Window and Session Managers
+.XS
+\*(SN Communication with Window and Session Managers
+.XE
+.LP
+The revision of the \fI\*(xC\fP as an X Consortium standard has resulted
+in the addition of three fields to the specification of
+.PN WMShellPart .
+These are \fIurgency\fP, \fIclient_leader\fP, and \fIwindow_role\fP.
+.LP
+The adoption of the \fIX Session Management Protocol\fP as an X Consortium
+standard has resulted in the addition of a new shell widget, 
+.PN SessionShell ,
+and an accompanying subclass verification interface,
+.PN XtIsSessionShell .
+This widget provides support for communication between an application
+and a session manager, as well as a window manager.
+In order to preserve compatibility with existing subclasses of 
+.PN ApplicationShell ,
+the 
+.PN ApplicationShell 
+was subclassed to create the new widget class.
+The session protocol requires a modal response to certain checkpointing
+operations by participating applications.  The
+.PN SessionShell
+structures
+the application's notification of and responses to messages from the session
+manager by use of various callback lists and by use of the new interfaces
+.PN XtSessionGetToken
+and 
+.PN XtSessionReturnToken .
+There is also a new command line argument, -xtsessionID, which facilitates
+the session manager in restarting applications based on the \*(xI.
+.LP
+The resource name and class strings defined by the \*(xI shell
+widgets in 
+.Pn < X11/Shell.h > 
+are now listed in Appendix E.  The addition of a new symbol
+for the 
+.PN WMShell
+\fIwait_for_wm\fP resource was made to bring the external symbol
+and the string it represents into agreement.  The actual resource name
+string in 
+.PN WMShell
+has not changed.
+The resource representation type of the XtNwinGravity resource of the 
+.PN WMShell
+was changed to XtRGravity in order to register a type 
+converter so that window gravity resource values could be specified by name.
+
+.NH 3
+Geometry Management
+.XS
+\*(SN Geometry Management
+.XE
+.LP
+A clarification to the specification was made to indicate that geometry
+requests may include current values along with the requested changes.
+
+.NH 3
+Event Management
+.XS
+\*(SN Event Management
+.XE
+.LP
+In Release 6, support is provided for registering selectors
+and event handlers for events generated by X protocol extensions
+and for dispatching those events to the appropriate widget.
+The new event handler registration interfaces are
+.PN XtInsertEventTypeHandler
+and
+.PN XtRemoveEventTypeHandler .
+Since the mechanism to indicate selection of extension events is specific
+to the extension being used, the \*(xI introduces 
+.PN XtRegisterExtensionSelector ,
+which allows the application to select for the events of interest.
+In order to change the dispatching algorithm to accommodate extension events
+as well as core X protocol events,
+the \*(xI event dispatcher may now be replaced or enveloped
+by the application with
+.PN XtSetEventDispatcher .
+The dispatcher may wish to call 
+.PN XtGetKeyboardFocusWidget
+to determine the widget with the current \*(xI keyboard focus.
+A dispatcher, after determining the destination widget, may use
+.PN XtDispatchEventToWidget
+to cause the event to be dispatched to the event handlers registered
+by a specific widget.
+.LP
+To permit the dispatching of events
+for nonwidget drawables, such as pixmaps that are not associated
+with a widget's window, 
+.PN XtRegisterDrawable
+and 
+.PN XtUnregisterDrawable
+have been added to the library.  A related update was made to
+the description of
+.PN XtWindowToWidget .
+.LP
+The library is now thread-safe, allowing one thread at a time to
+enter the library and protecting global data as necessary from concurrent use.
+Threaded toolkit applications are supported by the 
+new interfaces
+.PN XtToolkitThreadInitialize ,
+.PN XtAppLock ,
+.PN XtAppUnlock ,
+.PN XtAppSetExitFlag ,
+and 
+.PN XtAppGetExitFlag .
+Widget writers may also use 
+.PN XtProcessLock
+and 
+.PN XtProcessUnlock .
+.LP
+Safe handling of POSIX signals and other asynchronous notifications
+is now provided by use of 
+.PN XtAppAddSignal ,
+.PN XtNoticeSignal ,
+and
+.PN XtRemoveSignal .
+.LP
+The application can receive notification of an impending block
+in the \*(xI event manager by registering interest through
+.PN XtAppAddBlockHook
+and 
+.PN XtRemoveBlockHook .
+.LP
+.PN XtLastEventProcessed
+returns the most recent event passed to
+.PN XtDispatchEvent
+for a specified display.
+
+.NH 3
+Resource Management
+.XS
+\*(SN Resource Management
+.XE
+.LP
+Resource converters are registered by the \*(xI for window gravity
+and for three new resource types associated with session participation:
+RestartStyle, CommandArgArray and DirectoryString.
+.LP
+The file search path syntax has been extended to make it easier to
+include the default search path, which controls resource
+database construction, by using the new substitution string, %D.
+
+.NH 3
+Translation Management
+.XS
+\*(SN Translation Management
+.XE
+.LP
+The default key translator now recognizes the NumLock modifier.
+If NumLock is on and the second keysym is a keypad keysym
+(a standard keysym named with a ``KP'' prefix or a
+vendor-specific keysym in the hexadecimal range 0x11000000 to 0x1100FFFF),
+then the default key translator will
+use the first keysym if Shift and/or ShiftLock is on and will 
+use the second keysym if neither is on.  Otherwise, it will
+ignore NumLock and apply the normal protocol semantics.
+
+.NH 3
+Selections
+.XS
+\*(SN Selections
+.XE
+.LP
+The targets of selection requests may be parameterized, as described
+by the revised \fI\*(xC\fP.
+When such requests are made,
+.PN XtSetSelectionParameters
+is used by the requestor to specify the target parameters and
+.PN XtGetSelectionParameters
+is used by the selection owner to retrieve the parameters.
+When a parameterized target is specified in the context of a bundled
+request for multiple targets, 
+.PN XtCreateSelectionRequest ,
+.PN XtCancelSelectionRequest ,
+and 
+.PN XtSendSelectionRequest 
+are used to envelop the assembly of the request.
+When the parameters themselves are the names of properties, 
+the \*(xI provides support for the economical use of property atom names;
+see 
+.PN XtReservePropertyAtom
+and 
+.PN XtReleasePropertyAtom .
+
+.NH 3
+External Agent Hooks
+.XS
+\*(SN External Agent Hooks
+.XE
+.LP
+External agent hooks were added for the benefit of applications
+that instrument other applications for purposes of accessibility,
+testing, and customization.  The external agent and the application
+communicate by a shared protocol which is transparent to the application.
+The hook callbacks permit the external agent to register interest
+in groups or classes of toolkit activity and to be notified of the
+type and details of the activity as it occurs.  The new interfaces
+related to this effort are
+.PN XtHooksOfDisplay ,
+which returns the hook registration widget, and 
+.PN XtGetDisplays ,
+which returns a list of the X displays associated with an application context.
+.bp