1183 lines
43 KiB
XML
1183 lines
43 KiB
XML
<?xml version="1.0" encoding="UTF-8" ?>
|
|
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN" "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd">
|
|
|
|
<chapter id='Evolution_of_the_Intrinsics'>
|
|
<title>Evolution of the Intrinsics</title>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
The Intrinsics 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.
|
|
</para>
|
|
|
|
<para>
|
|
In particular, widget programmers may wish to conform to the convention
|
|
described in <xref linkend='Class_Extension_Records' /> when defining class extension records.
|
|
</para>
|
|
<sect1 id="Determining_Specification_Revision_Level">
|
|
<title>Determining Specification Revision Level</title>
|
|
<para>
|
|
Widget and application developers who wish to maintain a common source
|
|
pool that will build properly with implementations of the Intrinsics
|
|
at different revision levels of these specifications but that take
|
|
advantage of newer features added in later revisions may use the
|
|
symbolic macro
|
|
<function>XtSpecificationRelease</function>.
|
|
</para>
|
|
<programlisting>
|
|
#define XtSpecificationRelease 7
|
|
</programlisting>
|
|
<para>
|
|
As the symbol
|
|
<function>XtSpecificationRelease</function>
|
|
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.
|
|
</para>
|
|
</sect1>
|
|
|
|
<sect1 id="Release_to_Release_Compatibility">
|
|
<title>Release 3 to Release 4 Compatibility</title>
|
|
<para>
|
|
At the data structure level, Release 4 retains binary compatibility
|
|
with Release 3 (the first X Consortium standard release) for all data
|
|
structures except
|
|
<function>WMShellPart,</function>
|
|
<function>TopLevelShellPart</function>,
|
|
and
|
|
<function>TransientShellPart</function>.
|
|
Release 4 changed the argument type to most procedures that now take
|
|
arguments of type
|
|
<function>XtPointer</function>
|
|
and structure members that are now of type
|
|
<function>XtPointer</function>
|
|
in order to avoid potential ANSI C conformance problems. It is
|
|
expected that most implementations will be binary compatible with the
|
|
previous definition.
|
|
</para>
|
|
|
|
<para>
|
|
Two fields in
|
|
<function>CoreClassPart</function>
|
|
were changed from
|
|
<function>Boolean</function>
|
|
to
|
|
<function>XtEnum</function>
|
|
to allow implementations additional freedom in specifying the
|
|
representations of each. This change should require no source
|
|
modification.
|
|
</para>
|
|
<sect2 id="Additional_Arguments">
|
|
<title>Additional Arguments</title>
|
|
<para>
|
|
Arguments were added to the procedure definitions for
|
|
<xref linkend='XtInitProc' xrefstyle='select: title'/>,
|
|
<xref linkend='XtSetValuesFunc' xrefstyle='select: title'/>,
|
|
and
|
|
<xref linkend='XtEventHandler' xrefstyle='select: title'/>
|
|
to provide more information and to
|
|
allow event handlers to abort further dispatching of the current event
|
|
(caution is advised!). The added arguments to
|
|
<xref linkend='XtInitProc' xrefstyle='select: title'/>
|
|
and
|
|
<xref linkend='XtSetValuesFunc' xrefstyle='select: title'/>
|
|
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.
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2 id="set_values_almost_Procedures">
|
|
<title>set_values_almost Procedures</title>
|
|
<para>
|
|
The use of the arguments by a set_values_almost procedure was poorly
|
|
described in Release 3 and was inconsistent with other conventions.
|
|
</para>
|
|
|
|
<para>
|
|
The current specification for the manner in which a set_values_almost
|
|
procedure returns information to the Intrinsics 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.
|
|
</para>
|
|
|
|
<para>
|
|
No known implementation of the Intrinsics correctly implemented the
|
|
Release 3 interface, so it is expected that the impact of this
|
|
specification change is small.
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2 id="Query_Geometry">
|
|
<title>Query Geometry</title>
|
|
<para>
|
|
A composite widget layout routine that calls
|
|
<xref linkend='XtQueryGeometry' xrefstyle='select: title'/>
|
|
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.
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2 id="unrealizeCallback_Callback_List">
|
|
<title>unrealizeCallback Callback List</title>
|
|
<para>
|
|
In order to provide a mechanism for widgets to be notified when they
|
|
become unrealized through a call to
|
|
<xref linkend='XtUnrealizeWidget' xrefstyle='select: title'/>,
|
|
the callback
|
|
list name “unrealizeCallback” has been defined by the Intrinsics. 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.
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2 id="Subclasses_of_WMShell">
|
|
<title>Subclasses of WMShell</title>
|
|
<para>
|
|
The formal adoption of the <emphasis remap='I'>Inter-Client Communication Conventions Manual</emphasis> as
|
|
an X Consortium standard has meant the addition of four fields to
|
|
<function>WMShellPart</function>
|
|
and one field to
|
|
<function>TopLevelShellPart</function>.
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
To provide more convenience for TransientShells, a field was added
|
|
to the previously empty
|
|
<function>TransientShellPart</function>.
|
|
On some architectures the size of the part structure will not
|
|
have changed as a result of this.
|
|
</para>
|
|
|
|
<para>
|
|
Any widget implementation whose class is a subclass of
|
|
TopLevelShell
|
|
or
|
|
TransientShell
|
|
must at minimum be
|
|
recompiled with the new data structure declarations. Because
|
|
<function>WMShellPart</function>
|
|
no longer contains a contiguous
|
|
<function>XSizeHints</function>
|
|
data structure,
|
|
a subclass that expected to do a single structure assignment of an
|
|
<function>XSizeHints</function>
|
|
structure to the <emphasis remap='I'>size_hints</emphasis> field of
|
|
<function>WMShellPart</function>
|
|
must be revised, though the old fields remain at the same positions within
|
|
<function>WMShellPart</function>.
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2 id="Resource_Type_Converters">
|
|
<title>Resource Type Converters</title>
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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
|
|
<xref linkend='XtConverter' xrefstyle='select: title'/>
|
|
was incomplete.
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2 id="KeySym_Case_Conversion_Procedure">
|
|
<title>KeySym Case Conversion Procedure</title>
|
|
<para>
|
|
The specification for the
|
|
<xref linkend='XtCaseProc' xrefstyle='select: title'/>
|
|
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 Intrinsics
|
|
implemented the previously documented interface.
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2 id="Nonwidget_Objects_2">
|
|
<title>Nonwidget Objects</title>
|
|
<para>
|
|
Formal support for nonwidget objects is new to Release 4. A
|
|
prototype implementation was latent in at least one Release 3
|
|
implementation of the Intrinsics, but the specification has changed
|
|
somewhat. The most significant change is the requirement for a
|
|
composite widget to declare the
|
|
<function>CompositeClassExtension</function>
|
|
record with the <emphasis remap='I'>accepts_objects</emphasis> field set to
|
|
<function>True</function>
|
|
in order to permit a client to create a nonwidget child.
|
|
</para>
|
|
|
|
<para>
|
|
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
|
|
<emphasis remap='I'>accepts_objects</emphasis> field allows a composite widget to declare that it
|
|
is not prepared to do so.
|
|
</para>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="Release_to_Release_Compatibility_2">
|
|
<title>Release 4 to Release 5 Compatibility</title>
|
|
<para>
|
|
At the data structure level, Release 5 retains complete binary
|
|
compatibility with Release 4. The specification of the
|
|
<function>ObjectPart</function>,
|
|
<function>RectObjPart</function>,
|
|
<function>CorePart</function>,
|
|
<function>CompositePart</function>,
|
|
<function>ShellPart</function>,
|
|
<function>WMShellPart</function>,
|
|
<function>TopLevelShellPart</function>,
|
|
and
|
|
<function>ApplicationShellPart</function>
|
|
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
|
|
<function>XrmValue</function>
|
|
and
|
|
<function>XrmOptionDescRec</function>
|
|
was updated to use a new type,
|
|
<function>XPointer</function>,
|
|
for the <emphasis remap='I'>addr</emphasis> and <emphasis remap='I'>value</emphasis> fields, respectively, to avoid
|
|
ANSI C conformance problems. The definition of
|
|
<function>XPointer</function>
|
|
is binary compatible with the previous implementation.
|
|
</para>
|
|
<sect2 id="baseTranslations_Resource">
|
|
<title>baseTranslations Resource</title>
|
|
<para>
|
|
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”.
|
|
</para>
|
|
|
|
<para>
|
|
Applications wishing to take advantage of the new functionality
|
|
would change their application defaults file, e.g., from
|
|
<programlisting>
|
|
app.widget.translations: <emphasis remap='I'>value</emphasis>
|
|
to
|
|
app.widget.baseTranslations: <emphasis remap='I'>value</emphasis>
|
|
</programlisting>
|
|
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.
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2 id="Resource_File_Search_Path">
|
|
<title>Resource File Search Path</title>
|
|
<para>
|
|
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
|
|
<emphasis role='strong'>XFILESEARCHPATH</emphasis>
|
|
and
|
|
<emphasis role='strong'>XUSERFILESEARCHPATH</emphasis>
|
|
values when overriding the system defaults.
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2 id="Customization_Resource">
|
|
<title>Customization Resource</title>
|
|
<para>
|
|
<xref linkend='XtResolvePathname' xrefstyle='select: title'/>
|
|
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.
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2 id="Per_Screen_Resource_Database">
|
|
<title>Per-Screen Resource Database</title>
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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
|
|
<xref linkend='XtResolvePathname' xrefstyle='select: title'/>.
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2 id="Internationalization_of_Applications">
|
|
<title>Internationalization of Applications</title>
|
|
<para>
|
|
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 not to
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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
|
|
<function>XtSetLanguageProc</function>
|
|
to do so.
|
|
</para>
|
|
|
|
<para>
|
|
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
|
|
<xref linkend='XtDispatchEvent' xrefstyle='select: title'/>.
|
|
Applications that may not be dispatching all events through
|
|
<xref linkend='XtDispatchEvent' xrefstyle='select: title'/>
|
|
should be reviewed in the context of this new input method mechanism.
|
|
</para>
|
|
|
|
<para>
|
|
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 Intrinsics to locate the database from localization information
|
|
supplied by the client.
|
|
</para>
|
|
|
|
<para>
|
|
The previous specification for the syntax of the language string
|
|
specified by
|
|
<function>xnlLanguage</function>
|
|
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.
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2 id="Permanently_Allocated_Strings">
|
|
<title>Permanently Allocated Strings</title>
|
|
<para>
|
|
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 <emphasis remap='I'>class_name</emphasis>, <emphasis remap='I'>resource_name</emphasis>, <emphasis remap='I'>resource_class</emphasis>,
|
|
<emphasis remap='I'>resource_type</emphasis>, <emphasis remap='I'>default_type</emphasis> in resource tables, Core <emphasis remap='I'>actions</emphasis>
|
|
<emphasis remap='I'>string</emphasis> field, and Constraint <emphasis remap='I'>resource_name</emphasis>, <emphasis remap='I'>resource_class</emphasis>,
|
|
<emphasis remap='I'>resource_type</emphasis>, and <emphasis remap='I'>default_type</emphasis> resource fields to be
|
|
permanently allocated. This explicit requirement is expected to
|
|
affect only applications that may create and destroy classes
|
|
on the fly.
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2 id="Arguments_to_Existing_Functions">
|
|
<title>Arguments to Existing Functions</title>
|
|
<para>
|
|
The <emphasis remap='I'>args</emphasis> argument to
|
|
<xref linkend='XtAppInitialize' xrefstyle='select: title'/>,
|
|
<xref linkend='XtVaAppInitialize' xrefstyle='select: title'/>,
|
|
<xref linkend='XtOpenDisplay' xrefstyle='select: title'/>,
|
|
<xref linkend='XtDisplayInitialize' xrefstyle='select: title'/>,
|
|
and
|
|
<xref linkend='XtInitialize' xrefstyle='select: title'/>
|
|
were changed from
|
|
<function>Cardinal</function>*
|
|
to int* to conform to pre-existing convention and avoid otherwise
|
|
annoying typecasting in ANSI C environments.
|
|
</para>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="Release_to_Release_Compatibility_3">
|
|
<title>Release 5 to Release 6 Compatibility</title>
|
|
<para>
|
|
At the data structure level, Release 6 retains binary compatibility
|
|
with Release 5 for all data structures except
|
|
<function>WMShellPart</function>.
|
|
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.
|
|
</para>
|
|
<sect2 id="Widget_Internals">
|
|
<title>Widget Internals</title>
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
As a convenience, an interface to locate a widget class extension
|
|
record on a linked list,
|
|
<xref linkend='XtGetClassExtension' xrefstyle='select: title'/>,
|
|
has been added.
|
|
</para>
|
|
|
|
<para>
|
|
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 <function>True</function> in the
|
|
extension record.
|
|
</para>
|
|
|
|
<para>
|
|
The wording of the process followed by
|
|
<xref linkend='XtUnmanageChildren' xrefstyle='select: title'/>
|
|
has changed slightly to better handle changes to the managed set
|
|
during phase 2 destroy processing.
|
|
</para>
|
|
|
|
<para>
|
|
A new exposure event compression flag,
|
|
<function>XtExposeNoRegion</function>,
|
|
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 Intrinsics need not
|
|
compute the region.
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2 id="General_Application_Development">
|
|
<title>General Application Development</title>
|
|
<para>
|
|
<xref linkend='XtOpenApplication' xrefstyle='select: title'/>
|
|
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,
|
|
<xref linkend='XtAppInitialize' xrefstyle='select: title'/>,
|
|
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.
|
|
</para>
|
|
|
|
<para>
|
|
The toolkit initialization function
|
|
<xref linkend='XtToolkitInitialize' xrefstyle='select: title'/>
|
|
may be called multiple times without penalty.
|
|
</para>
|
|
|
|
<para>
|
|
In order to optimize changes in geometry to a set of geometry-managed
|
|
children, a new interface,
|
|
<xref linkend='XtChangeManagedSet' xrefstyle='select: title'/>,
|
|
has been added.
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2 id="Communication_with_Window_and_Session_Managers">
|
|
<title>Communication with Window and Session Managers</title>
|
|
<para>
|
|
The revision of the <emphasis remap='I'>Inter-Client Communication Conventions Manual</emphasis> as an X Consortium standard has resulted
|
|
in the addition of three fields to the specification of
|
|
<function>WMShellPart</function>.
|
|
These are <emphasis remap='I'>urgency</emphasis>, <emphasis remap='I'>client_leader</emphasis>, and <emphasis remap='I'>window_role</emphasis>.
|
|
</para>
|
|
|
|
<para>
|
|
The adoption of the <emphasis remap='I'>X Session Management Protocol</emphasis> as an X Consortium
|
|
standard has resulted in the addition of a new shell widget,
|
|
<function>SessionShell</function>,
|
|
and an accompanying subclass verification interface,
|
|
<function>XtIsSessionShell</function>.
|
|
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
|
|
<function>ApplicationShell</function>,
|
|
the
|
|
<function>ApplicationShell</function>
|
|
was subclassed to create the new widget class.
|
|
The session protocol requires a modal response to certain checkpointing
|
|
operations by participating applications. The
|
|
<function>SessionShell</function>
|
|
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
|
|
<xref linkend='XtSessionGetToken' xrefstyle='select: title'/>
|
|
and
|
|
<xref linkend='XtSessionReturnToken' xrefstyle='select: title'/>.
|
|
There is also a new command line argument, -xtsessionID, which facilitates
|
|
the session manager in restarting applications based on the Intrinsics.
|
|
</para>
|
|
|
|
<para>
|
|
The resource name and class strings defined by the Intrinsics shell
|
|
widgets in
|
|
<filename class="headerfile"><X11/Shell.h></filename>
|
|
are now listed in Appendix E. The addition of a new symbol
|
|
for the
|
|
<function>WMShell</function>
|
|
<emphasis remap='I'>wait_for_wm</emphasis> resource was made to bring the external symbol
|
|
and the string it represents into agreement. The actual resource name
|
|
string in
|
|
<function>WMShell</function>
|
|
has not changed.
|
|
The resource representation type of the XtNwinGravity resource of the
|
|
<function>WMShell</function>
|
|
was changed to XtRGravity in order to register a type
|
|
converter so that window gravity resource values could be specified by name.
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2 id="Geometry_Management_2">
|
|
<title>Geometry Management</title>
|
|
<para>
|
|
A clarification to the specification was made to indicate that geometry
|
|
requests may include current values along with the requested changes.
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2 id="Event_Management_2">
|
|
<title>Event Management</title>
|
|
<para>
|
|
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
|
|
<xref linkend='XtInsertEventTypeHandler' xrefstyle='select: title'/>
|
|
and
|
|
<xref linkend='XtRemoveEventTypeHandler' xrefstyle='select: title'/>.
|
|
Since the mechanism to indicate selection of extension events is specific
|
|
to the extension being used, the Intrinsics introduces
|
|
<xref linkend='XtRegisterExtensionSelector' xrefstyle='select: title'/>,
|
|
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 Intrinsics event dispatcher may now be replaced or enveloped
|
|
by the application with
|
|
<xref linkend='XtSetEventDispatcher' xrefstyle='select: title'/>.
|
|
The dispatcher may wish to call
|
|
<xref linkend='XtGetKeyboardFocusWidget' xrefstyle='select: title'/>
|
|
to determine the widget with the current Intrinsics keyboard focus.
|
|
A dispatcher, after determining the destination widget, may use
|
|
<xref linkend='XtDispatchEventToWidget' xrefstyle='select: title'/>
|
|
to cause the event to be dispatched to the event handlers registered
|
|
by a specific widget.
|
|
</para>
|
|
|
|
<para>
|
|
To permit the dispatching of events
|
|
for nonwidget drawables, such as pixmaps that are not associated
|
|
with a widget's window,
|
|
<xref linkend='XtRegisterDrawable' xrefstyle='select: title'/>
|
|
and
|
|
<xref linkend='XtUnregisterDrawable' xrefstyle='select: title'/>
|
|
have been added to the library. A related update was made to
|
|
the description of
|
|
<xref linkend='XtWindowToWidget' xrefstyle='select: title'/>.
|
|
</para>
|
|
|
|
<para>
|
|
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
|
|
<xref linkend='XtToolkitThreadInitialize' xrefstyle='select: title'/>,
|
|
<xref linkend='XtAppLock' xrefstyle='select: title'/>,
|
|
<xref linkend='XtAppUnlock' xrefstyle='select: title'/>,
|
|
<xref linkend='XtAppSetExitFlag' xrefstyle='select: title'/>,
|
|
and
|
|
<xref linkend='XtAppGetExitFlag' xrefstyle='select: title'/>.
|
|
Widget writers may also use
|
|
<xref linkend='XtProcessLock' xrefstyle='select: title'/>
|
|
and
|
|
<xref linkend='XtProcessUnlock' xrefstyle='select: title'/>.
|
|
</para>
|
|
|
|
<para>
|
|
Safe handling of POSIX signals and other asynchronous notifications
|
|
is now provided by use of
|
|
<xref linkend='XtAppAddSignal' xrefstyle='select: title'/>,
|
|
<xref linkend='XtNoticeSignal' xrefstyle='select: title'/>,
|
|
and
|
|
<xref linkend='XtRemoveSignal' xrefstyle='select: title'/>.
|
|
</para>
|
|
|
|
<para>
|
|
The application can receive notification of an impending block
|
|
in the Intrinsics event manager by registering interest through
|
|
<xref linkend='XtAppAddBlockHook' xrefstyle='select: title'/>
|
|
and
|
|
<xref linkend='XtRemoveBlockHook' xrefstyle='select: title'/>.
|
|
</para>
|
|
|
|
<para>
|
|
<xref linkend='XtLastEventProcessed' xrefstyle='select: title'/>
|
|
returns the most recent event passed to
|
|
<xref linkend='XtDispatchEvent' xrefstyle='select: title'/>
|
|
for a specified display.
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2 id="Resource_Management_2">
|
|
<title>Resource Management</title>
|
|
<para>
|
|
Resource converters are registered by the Intrinsics for window gravity
|
|
and for three new resource types associated with session participation:
|
|
RestartStyle, CommandArgArray and DirectoryString.
|
|
</para>
|
|
|
|
<para>
|
|
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.
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2 id="Translation_Management_2">
|
|
<title>Translation Management</title>
|
|
<para>
|
|
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.
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2 id="Selections">
|
|
<title>Selections</title>
|
|
<para>
|
|
The targets of selection requests may be parameterized, as described
|
|
by the revised <emphasis remap='I'>Inter-Client Communication Conventions Manual</emphasis>.
|
|
When such requests are made,
|
|
<xref linkend='XtSetSelectionParameters' xrefstyle='select: title'/>
|
|
is used by the requestor to specify the target parameters and
|
|
<xref linkend='XtGetSelectionParameters' xrefstyle='select: title'/>
|
|
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,
|
|
<xref linkend='XtCreateSelectionRequest' xrefstyle='select: title'/>,
|
|
<xref linkend='XtCancelSelectionRequest' xrefstyle='select: title'/>,
|
|
and
|
|
<xref linkend='XtSendSelectionRequest' xrefstyle='select: title'/>
|
|
are used to envelop the assembly of the request.
|
|
When the parameters themselves are the names of properties,
|
|
the Intrinsics provides support for the economical use of property atom names;
|
|
see
|
|
<xref linkend='XtReservePropertyAtom' xrefstyle='select: title'/>
|
|
and
|
|
<xref linkend='XtReleasePropertyAtom' xrefstyle='select: title'/>.
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2 id="External_Agent_Hooks">
|
|
<title>External Agent Hooks</title>
|
|
<para>
|
|
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
|
|
<xref linkend='XtHooksOfDisplay' xrefstyle='select: title'/>,
|
|
which returns the hook registration widget, and
|
|
<xref linkend='XtGetDisplays' xrefstyle='select: title'/>,
|
|
which returns a list of the X displays associated with an application context.
|
|
</para>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="Release_to_Release_Compatibility_4">
|
|
<title>Release 6 to Release 7 Compatibility</title>
|
|
|
|
<sect2 id="Changes_During_X11R6">
|
|
<title>Changes During X11R6</title>
|
|
<para>
|
|
The Toolkit was proposed in X10R4, released at the end of 1986.
|
|
The X11R6 documentation was completed in mid–1994.
|
|
Over most of the eleven years through X11R6.9,
|
|
only minor changes were made to the specification.
|
|
Some changes are documented only in the release notes:
|
|
</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
The X11R6.3 release notes (1997) mention one new feature (section 3.15)
|
|
<emphasis remap='I'>Xt Geometry Management Debugger</emphasis>, saying
|
|
</para>
|
|
<blockquote>
|
|
<para>
|
|
Daniel Dardailler's “GeoTattler” code has been merged into the Xt
|
|
Intrinsics library implementation.
|
|
This is not a standard.
|
|
If libXt is compiled with the <code>XT_GEO_TATTLER</code> symbol defined
|
|
(currently there is no build configuration support to do this)
|
|
then a “geoTattler” resource
|
|
may be specified for any widget in an application.
|
|
If the <code>geoTattler</code>
|
|
resource for a widget instance is <code>True</code>
|
|
then libXt will generate debugging information to
|
|
<emphasis remap='I'>stdout</emphasis> when the widget makes geometry change requests.
|
|
</para>
|
|
<para>
|
|
For example, if the resources specify:
|
|
</para>
|
|
<programlisting>
|
|
myapp*draw.XmScale.geoTattler: ON
|
|
*XmScrollBar.geoTattler:ON
|
|
*XmRowColumn.exit_button.geoTattler:ON
|
|
</programlisting>
|
|
<para>
|
|
then geometry management debugging information will be generated for all
|
|
the <code>XmScale</code> children
|
|
of the widget named <emphasis remap='I'>draw</emphasis>,
|
|
all the XmScrollBars,
|
|
and the widget named <emphasis remap='I'>exit_button</emphasis>
|
|
in any <code>XmRowColumn</code>.
|
|
</para>
|
|
</blockquote>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
X11R6.4 (1998) added
|
|
<xref linkend='Resource_Configuration_Management' />.
|
|
The release notes explain that by saying
|
|
<blockquote>
|
|
<para>
|
|
The X Toolkit Intrinsics library (libXt) now has IBM's Easy Resource
|
|
Configuration support included.
|
|
</para>
|
|
</blockquote>
|
|
</para>
|
|
<para>
|
|
but goes on to say (section 14) that
|
|
<blockquote>
|
|
<para>
|
|
Easy Resource Configuration
|
|
is not a standard part of the X Toolkit Intrinsics (libXt).
|
|
It is neither an X Consortium standard nor an X Project Team specification.
|
|
</para>
|
|
</blockquote>
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
X11R6.5 (2000) documented a bug-fix for XtAppPeekEvent in the release notes,
|
|
stating that it now worked as described in the specification.
|
|
It also modified the description of XtAppPeekEvent in the specification.
|
|
Previously the specification stated that no known implementations behaved
|
|
as specified.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Subsequent releases X11R6.6 (2001) through X11R6.9 (2005)
|
|
did not document any new or improved features.
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
<para>
|
|
Throughout this interval,
|
|
there were undocumented fixes and improvements made to the X Toolkit Intrinsics library.
|
|
The documentation was modified to fix minor errors,
|
|
improve the formatting, and
|
|
update version numbers.
|
|
</para>
|
|
</sect2>
|
|
<sect2 id="Changes_During_X11R7">
|
|
<title>Changes During X11R7</title>
|
|
<para>
|
|
X11R7 releases starting in 2005 continued this trend,
|
|
converting the documentation from nroff to sgml.
|
|
X11R7.7 (2012) provides the same Intrinsics specification
|
|
(aside from details of formatting and version numbers) as X11R6 (1995).
|
|
</para>
|
|
<para>
|
|
The updates for this specification are a continuation of X11R7.7,
|
|
because (as of April 2019) there are no plans for an X11R7.8 release.
|
|
</para>
|
|
</sect2>
|
|
<sect2 id="Converting_to_Standard_C">
|
|
<title>Converting to Standard C</title>
|
|
<para>
|
|
The Intrinsics specification was first released with X11R3 in 1989.
|
|
That was too early to take Standard C (i.e., ANSI C) into account.
|
|
Because vendors generally did not provide a no-cost Standard C compiler,
|
|
the X Toolkit Intrinsics library initially supported both K&R and ANSI C.
|
|
The X11R5 release notes mention using gcc, with some caveats.
|
|
As a result, the specification and implementation gave equal attention
|
|
to both K&R and ANSI C.
|
|
</para>
|
|
<para>
|
|
This example shows how a function prototype was used in the C header files:
|
|
</para>
|
|
<programlisting>
|
|
extern Display *XtOpenDisplay(
|
|
#if NeedFunctionPrototypes
|
|
XtAppContext /* app_context */,
|
|
_Xconst _XtString /* display_string */,
|
|
_Xconst _XtString /* application_name */,
|
|
_Xconst _XtString /* application_class */,
|
|
XrmOptionDescRec* /* options */,
|
|
Cardinal /* num_options */,
|
|
int* /* argc */,
|
|
char** /* argv */
|
|
#endif
|
|
);
|
|
</programlisting>
|
|
<para>
|
|
The parameters for the ANSI C prototype were conditionally compiled.
|
|
Used with a K&R compiler, those parameters were ignored.
|
|
</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
The X Toolkit Intrinsics library used <type>const</type> in just a few cases.
|
|
The specification did not mention it at all.
|
|
</para>
|
|
<para>
|
|
Over time, that was seen as a problem,
|
|
partly because of gcc's warning options
|
|
such as <emphasis remap='I'>write-strings</emphasis>,
|
|
introduced in early 1988 (released with gcc 1.27 in late 1988).
|
|
Quoting from gcc 2.58's documentation (late 1993):
|
|
<programlisting>
|
|
`-Wwrite-strings'
|
|
Give string constants the type `const char[LENGTH]' so that
|
|
copying the address of one into a non-`const' `char *' pointer
|
|
will get a warning. These warnings will help you find at compile
|
|
time code that can try to write into a string constant, but only
|
|
if you have been very careful about using `const' in declarations
|
|
and prototypes. <emphasis remap='I'>Otherwise, it will just be a nuisance; this is
|
|
why we did not make `-Wall' request these warnings.</emphasis>
|
|
</programlisting>
|
|
</para>
|
|
<para>
|
|
Others did not agree that it was a nuisance. Besides the obvious advantage
|
|
of improving program correctness, making a symbol “const”
|
|
gave the compiler and linker a hint that the symbol could be put into
|
|
the text (read-only) section, eliminating some steps needed by the linker
|
|
to adjust addresses and thereby reducing the time it took to load a
|
|
program into memory.
|
|
</para>
|
|
<para>
|
|
Other gcc warning options (such as
|
|
such as <emphasis remap='I'>cast-qual</emphasis>)
|
|
are useful for improving programs.
|
|
They give similar information, because unless told otherwise,
|
|
gcc would treat string values as nonwritable.
|
|
Quoting from gcc 1.27:
|
|
<programlisting>
|
|
* GNU CC normally makes string constants read-only. If several
|
|
identical-looking string constants are used, GNU CC stores only
|
|
one copy of the string.
|
|
...
|
|
The best solution to these problems is to change the program to
|
|
use `char'-array variables with initialization strings for these
|
|
purposes instead of string constants. But if this is not
|
|
possible, you can use the `-fwritable-strings' flag, which
|
|
directs GNU CC to handle string constants the same way most C
|
|
compilers do.
|
|
</programlisting>
|
|
and
|
|
<programlisting>
|
|
`-fwritable-strings'
|
|
Store string constants in the writable data segment and
|
|
don't uniquize them. This is for compatibility with old
|
|
programs which assume they can write into string constants.
|
|
Writing into string constants is a very bad idea;
|
|
``constants'' should be constant.
|
|
</programlisting>
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Several prototypes in the implementation
|
|
use the private type <type>_XtString</type>.
|
|
The specification and implementation also used a <type>String</type>
|
|
type without explaining when it is appropriate.
|
|
<programlisting>
|
|
typedef char *String;
|
|
|
|
/* We do this in order to get "const" declarations to work right. We
|
|
* use _XtString instead of String so that C++ applications can
|
|
* #define String to something else if they choose, to avoid conflicts
|
|
* with other C++ libraries.
|
|
*/
|
|
#define _XtString char*
|
|
</programlisting>
|
|
That is, the developers were providing for some workaround to allow
|
|
C++ applications to use the stricter compiler checking
|
|
associated with <type>const</type>.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
The <type>String</type> type is not the only type used in the
|
|
prototypes for the X Toolkit Intrinsics library.
|
|
Its developers were also concerned with porting the library
|
|
to platforms with different size-constraints.
|
|
They defined different types (used in the function prototypes)
|
|
depending on whether a “wide” parameter type was appropriate:
|
|
<programlisting>
|
|
/* _Xt names are private to Xt implementation, do not use in client code */
|
|
#if NeedWidePrototypes
|
|
#define _XtBoolean int
|
|
#define _XtDimension unsigned int
|
|
#define _XtKeyCode unsigned int
|
|
#define _XtPosition int
|
|
#define _XtXtEnum unsigned int
|
|
#else
|
|
#define _XtBoolean Boolean
|
|
#define _XtDimension Dimension
|
|
#define _XtKeyCode KeyCode
|
|
#define _XtPosition Position
|
|
#define _XtXtEnum XtEnum
|
|
#endif /* NeedWidePrototypes */
|
|
</programlisting>
|
|
and
|
|
<programlisting>
|
|
#ifdef CRAY
|
|
typedef long Boolean;
|
|
typedef char* XtArgVal;
|
|
typedef long XtEnum;
|
|
#else
|
|
typedef char Boolean;
|
|
typedef long XtArgVal;
|
|
typedef unsigned char XtEnum;
|
|
#endif
|
|
</programlisting>
|
|
In practice, wide-prototypes are rarely used, not well supported.
|
|
The specification did not clarify the distinction
|
|
between <type>Bool</type> (mentioned as a resource type)
|
|
and <type>Boolean</type> (used in all of the data structures).
|
|
The implementation used both, predominantly the latter.
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
<para>
|
|
Other features of Standard C were neglected in the specification because
|
|
it was accommodating K&R C:
|
|
</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
K&R C has no <type>void</type> keyword.
|
|
The specification used it for return-types,
|
|
but not to indicate an empty parameter list.
|
|
The specification also stated that
|
|
<type>void*</type> would be used for the <type>XtPointer</type> type.
|
|
</para>
|
|
<para>
|
|
The conversion to sgml lost the <type>void</type> return-type.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Standard C uses an ellipsis for variable-length argument lists, e.g., for
|
|
<xref linkend='XtVaAppCreateShell' />.
|
|
Again, there was a conditional-compilation symbol
|
|
(<code>NeedVarargsPrototypes</code>)
|
|
to handle the different forms used.
|
|
Here is an example:
|
|
<programlisting>
|
|
#if NeedVarargsPrototypes
|
|
void
|
|
XtVaGetApplicationResources(Widget widget, XtPointer base, XtResourceList resources, Cardinal num_resources, ...)
|
|
#else
|
|
/*VARARGS4*/
|
|
void XtVaGetApplicationResources(widget, base, resources, num_resources, va_alist)
|
|
Widget widget;
|
|
XtPointer base;
|
|
XtResourceList resources;
|
|
Cardinal num_resources;
|
|
va_dcl
|
|
#endif
|
|
</programlisting>
|
|
</para>
|
|
<para>
|
|
One problem with the conditional-compilation was
|
|
that it was easy to make a mistake with the order
|
|
of parameters between the two forms.
|
|
Developers would frequently group together parameters
|
|
which used the same type, whether or not they were adjacent in
|
|
the Standard C prototype.
|
|
</para>
|
|
<para>
|
|
A comment in the X11R4 header file said that this was temporary,
|
|
until function prototypes worked everywhere.
|
|
That was finally removed in X11R6.7 (fourteen years later).
|
|
However, the subsequent conversion to sgml
|
|
lost the ellipsis from the prototypes shown in the specification.
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
<para>
|
|
Support for K&R C was removed from the header files in 2003
|
|
(released in X11R6.7),
|
|
and from the library source in 2004
|
|
(released in X11R6.9).
|
|
The wide-prototype feature is still present in 2019, but generally unused.
|
|
</para>
|
|
<para>
|
|
Removing support for K&R C did not address the issues of <type>const</type>.
|
|
That was done in 2019:
|
|
</para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
The <type>String</type> is conditionally defined,
|
|
to provide compatibility with existing applications.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
If the symbol <symbol>_CONST_X_STRING</symbol> is defined,
|
|
<type>String</type> is read-only as shown here.
|
|
<programlisting>
|
|
/*
|
|
* As used in its function interface, the String type of libXt can be readonly.
|
|
* But compiling libXt with this feature may require some internal changes,
|
|
* e.g., casts and occasionally using a plain "char*".
|
|
*/
|
|
#ifdef _CONST_X_STRING
|
|
typedef const char *String;
|
|
#else
|
|
typedef char *String;
|
|
#endif
|
|
</programlisting>
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Applications which use the newer <type>const</type> feature must define
|
|
<symbol>_CONST_X_STRING</symbol> to enable this feature.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
By default, the X Toolkit Intrinsics library
|
|
uses the <type>const</type> feature.
|
|
It has been updated to make use of the <type>const</type> feature
|
|
for improved type-checking.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Because the X Toolkit Intrinsics library uses <type>const</type>,
|
|
some prototypes have been modified.
|
|
For example:
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
Most of the parameters which used <type>String</type> are unmodified;
|
|
a few (such as the <emphasis remap='I'>argv</emphasis>–parameters)
|
|
are actually read/write.
|
|
They are now <type>char*</type> parameters.
|
|
</para>
|
|
<para>
|
|
Many of the strings passed to the library are stored in widgets
|
|
without reallocating a copy.
|
|
Those are treated as read-only, and use the <type>String</type> type.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Each change to the documentation was verified using scripts that
|
|
extracted the function prototypes and used the C compiler to check
|
|
for compatibility.
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</sect2>
|
|
</sect1>
|
|
</chapter>
|