1471 lines
59 KiB
HTML
1471 lines
59 KiB
HTML
<html>
|
|
<head>
|
|
<!-- This file has been generated by unroff 1.0, 03/21/96 19:25:21. -->
|
|
<!-- Do not edit! -->
|
|
<link rev="made" href="mailto:net@informatik.uni-bremen.de">
|
|
<title>X11R6 Release Notes, section 4.</title>
|
|
</head><body>
|
|
<h2><a name="section35">4.</a> <tt> </tt>What Is New in Release 6
|
|
<a name="toc35"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
This section describes changes in the X Consortium distribution since
|
|
Release 5. Release 6 contains much new functionality in many areas.<tt> </tt>
|
|
In addition, many bugs have been fixed. However, in the effort to
|
|
develop the new technology in this release, some bugs, particularly in
|
|
client programs, did not get fixed.<tt> </tt>
|
|
<p>
|
|
Except where noted, all libraries, protocols, and servers are upward
|
|
compatible with Release 5. That is, R5 clients and applications should
|
|
continue to work with R6 libraries and servers.<tt> </tt>
|
|
|
|
<h2><a name="section36">4.1.</a> <tt> </tt>New Standards
|
|
<a name="toc36"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
The following are new X Consortium standards in Release 6.<tt> </tt>
|
|
Each is described in its own section below.<tt> </tt>
|
|
<dl><dt><dd>
|
|
<pre>
|
|
X Image Extension
|
|
Inter-Client Communications Conventions Manual (update)
|
|
Inter-Client Exchange Protocol
|
|
Inter-Client Exchange Library
|
|
X Session Management Protocol
|
|
X Session Management Library
|
|
Input Method Protocol
|
|
X Logical Font Descriptions (update)
|
|
SYNC extension
|
|
XTEST extension
|
|
PEX 5.1 Protocol (released after R5)
|
|
PEXlib (released after R5)
|
|
BIG-REQUESTS extension
|
|
XC-MISC extension
|
|
</pre>
|
|
</dl>
|
|
|
|
<h2><a name="section37">4.2.</a> <tt> </tt>XIE (X Image Extension)
|
|
<a name="toc37"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
The sample implementation in Release 6 is a complete implementation of
|
|
full XIE 5.0 protocol, except for the
|
|
following techniques that are excluded from the SI:
|
|
<dl><dt><dd>
|
|
<pre>
|
|
ColorAlloc: Match, Requantize
|
|
Convolve: Replicate
|
|
Decode: JPEG lossless
|
|
Encode: JPEG lossless
|
|
Geometry: AntialiasByArea, AntialiasByLowpass
|
|
</pre>
|
|
</dl>
|
|
<p>
|
|
<i>xieperf</i> exercises the server functionality; it provides unit testing and
|
|
a reasonable measure of multi-element photoflo testing.<tt> </tt>
|
|
<p>
|
|
A draft standard of the XIElib specification is included in this
|
|
release and is open for Public Review.<tt> </tt>
|
|
The XIElib code matches the 5.0 protocol.<tt> </tt>
|
|
<p>
|
|
The JPEG compression and decompression code is based on the Independent JPEG
|
|
Group's (IJG) JPEG software, Release 4. This software provides baseline
|
|
Huffman DCT encoding as defined by ISO/IEC DIS 10918-1, ``Digital Compression
|
|
and Coding of Continuous-tone Still Images, Part 1: Requirements and
|
|
guidelines'', and was chosen as a basis for our implementation of JPEG
|
|
compression and decompression primarily because the IJG's design goals matched
|
|
ours for the implementation of the XIE SI: achieve portability and flexibility
|
|
without sacrificing performance. Less than half of the files distributed by
|
|
the IJG have been incorporated into the XIE SI. The IJG's software is made
|
|
available with restrictions; see
|
|
<b>xc/programs/Xserver/XIE/mixie/jpeg/README</b>.<tt> </tt>
|
|
|
|
<h2><a name="section38">4.3.</a> <tt> </tt>Inter-Client Communications Conventions Manual
|
|
<a name="toc38"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
Release 6 includes version 2.0 of the ICCCM. This version contains a
|
|
large number of changes and clarifications in the areas of window
|
|
management, selections, session management, and resource sharing.<tt> </tt>
|
|
|
|
<h2><a name="section39">4.3.1.</a> <tt> </tt>Window Management
|
|
<a name="toc39"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
The circumstances under which the window manager is required to send
|
|
synthetic ConfigureNotify events have been clarified to ensure that
|
|
any ConfigureWindow request issued by the
|
|
client will result in a ConfigureNotify event, either from the server
|
|
or from the window manager. We have also added advice about how a
|
|
client should inspect events so as to minimize the number of
|
|
situations where it is necessary to use the TranslateCoordinates
|
|
request.<tt> </tt>
|
|
<p>
|
|
The window_gravity field of WM_NORMAL_HINTS has a
|
|
new value, StaticGravity, which specifies that the
|
|
window manager should not shift the client window's location when reparenting
|
|
the window.<tt> </tt>
|
|
<p>
|
|
The base size in
|
|
the WM_NORMAL_HINTS property is now to be included in the aspect ratio
|
|
calculation.<tt> </tt>
|
|
<p>
|
|
The WM_STATE property now has a formal definition (it was previously
|
|
only suggested).<tt> </tt>
|
|
|
|
<h2><a name="section40">4.3.2.</a> <tt> </tt>Selections
|
|
<a name="toc40"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
We have clarified the CLIENT_WINDOW, LENGTH, and MULTIPLE
|
|
targets. We have also added a number of new targets for Encapsulated
|
|
PostScript and for the Apple Macintosh PICT structured graphics format. We
|
|
have also defined a new selection property type C_STRING, which is a string of
|
|
non-zero bytes. (This is in contrast to the STRING type, which excludes many
|
|
control characters.)
|
|
<p>
|
|
A selection requester can now pass parameters in with the request.<tt> </tt>
|
|
<p>
|
|
Another new facility is manager selections. This use of the selection
|
|
mechanism is not to transfer data, but to allow clients known as <i>managers</i>
|
|
to provide services to other clients. Version 2.0 also specifies that window
|
|
managers should hold a manager selection. At present, the only service
|
|
defined for window managers is to report the ICCCM version number to which the
|
|
window manager complies. Now that this facility is in place, additional
|
|
services can be added in the future.<tt> </tt>
|
|
|
|
<h2><a name="section41">4.3.3.</a> <tt> </tt>Resource Sharing
|
|
<a name="toc41"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
A prominent new addition in version 2.0 is the ability of clients to take
|
|
control of colormap installation under certain circumstances. Earlier
|
|
versions of the ICCCM specified that the window manager had exclusive control
|
|
over colormap installation. This proves to be inconvenient for certain
|
|
situations, such as when a client has the server grabbed. Version 2.0 allows
|
|
clients to install colormaps themselves after having informed the window
|
|
manager. Clients must hold a pointer grab for the entire time they are doing
|
|
their own colormap installation.<tt> </tt>
|
|
<p>
|
|
Version 2.0 also clarifies a number of rules about how clients can exchange
|
|
resources. These rules are important when a client places a resource ID into
|
|
a hints property or passes a resource ID through the selection mechanism.<tt> </tt>
|
|
|
|
<h2><a name="section42">4.3.4.</a> <tt> </tt>Session Management
|
|
<a name="toc42"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
Some of the properties in section 5 of ICCCM 1.1 are now obsolete, and
|
|
new properties for session management have been defined.<tt> </tt>
|
|
|
|
<h2><a name="section43">4.4.</a> <tt> </tt>ICE (Inter-Client Exchange)
|
|
<a name="toc43"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
ICE provides a
|
|
common framework to build protocols on. It supplies authentication, byte order
|
|
negotiation, version negotiation, and error reporting
|
|
conventions. It supports multiplexing multiple protocols over a single
|
|
transport connection. ICElib provides a common interface to these mechanisms
|
|
so that protocol implementors need not reinvent them.<tt> </tt>
|
|
<p>
|
|
An <i>iceauth</i> program was written to manipulate an ICE authority
|
|
file; it is very similar to the <i>xauth</i> program.<tt> </tt>
|
|
|
|
<h2><a name="section44">4.5.</a> <tt> </tt>SM (Session Management)
|
|
<a name="toc44"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
The X Session Management Protocol (XSMP) provides a
|
|
uniform mechanism for users to save and restore their sessions
|
|
using the services of a network-based session manager.<tt> </tt>
|
|
It is built on ICE. SMlib is the C interface to the protocol.<tt> </tt>
|
|
There is also support for XSMP in Xt.<tt> </tt>
|
|
<p>
|
|
A simple session manager, <i>xsm</i> is included in
|
|
<b>xc/workInProgress/xsm</b>.<tt> </tt>
|
|
<p>
|
|
A new protocol, rstart, greatly simplifies the task of starting applications
|
|
on remote machines. It is built upon already existing remote execution
|
|
protocols such as <i>rsh</i>. The most important feature that it adds is the
|
|
ability to pass environment variables and authentication data to the
|
|
applications being started.<tt> </tt>
|
|
|
|
<h2><a name="section45">4.6.</a> <tt> </tt>Input Method Protocol
|
|
<a name="toc45"> </a>
|
|
</h2>
|
|
<p>
|
|
Some languages need complex pre-editing input methods, and such an
|
|
input method may be implemented separately from applications in a
|
|
process called an Input Method (IM) Server. The IM Server handles the
|
|
display of pre-edit text and the user's input operation. The Input
|
|
Method (IM) Protocol standardizes the communication between the IM
|
|
Server and the IM library linked with the application.<tt> </tt>
|
|
<p>
|
|
The IM Protocol is a completely new protocol, based on experience with R5's
|
|
sample implementations. The following new features are added, beyond the
|
|
mechanisms in the R5 sample implementations:
|
|
<ul>
|
|
<li>
|
|
The IM Server can support any of several transports for connection with
|
|
the IM library.<tt> </tt>
|
|
<li>
|
|
Both the IM Server and clients can authenticate each other for security.<tt> </tt>
|
|
<li>
|
|
A client can connect to an IM Server without restarting even if
|
|
it starts up before the IM Server.<tt> </tt>
|
|
<li>
|
|
A client can initiate string conversion to the IM Server for re-conversion
|
|
of text.<tt> </tt>
|
|
<li>
|
|
A client can specify some keys as hot keys, which can be used to escape
|
|
from the normal input method processing regardless of the input method state.<tt> </tt>
|
|
</ul>
|
|
<p>
|
|
The R6 sample implementation for the internationalization support in Xlib has
|
|
a new pluggable framework, with the capability of loading and switching locale
|
|
object modules dynamically. For backward compatibility, the R6 sample
|
|
implementation can support the R5 protocols by switching to IM modules
|
|
supporting those protocols. In addition, the framework provides the following
|
|
new functions and mechanisms:
|
|
<dl>
|
|
<dt>X Locale database format:<dd>
|
|
An X Locale database format is defined, and the
|
|
subset of a user's environment dependent on language is provided as a plain
|
|
ASCII text file. You can customize the behavior of Xlib without changing
|
|
Xlib itself.<tt> </tt>
|
|
<dt>ANSI C and non-ANSI C bindings<dd>
|
|
The common set of methods and structures
|
|
are defined, which bind the X locale to the system locales within libc, and
|
|
a framework for implementing this common set under non-ANSI C base system is
|
|
provided.<tt> </tt>
|
|
<dt>Converters<dd>
|
|
The sample implementation has a mechanism to support various
|
|
encodings by pluggable converters, and provides the following converters:
|
|
<dl><dt><dd>
|
|
<pre>
|
|
- Light weight converter for C and ISO 8859
|
|
- Generic converter (relatively slow) for other encoding
|
|
- High performance converter for Shift-JIS and EUC
|
|
- Converter for UCS-2 defined in ISO/IEC 10646-1
|
|
</pre>
|
|
</dl>
|
|
You can add your converter using this mechanism for your
|
|
specific performance requirement.
|
|
<dt>Locale modules<dd>
|
|
The library is implemented such that input methods and
|
|
output methods are separated and are independent of each other. Therefore,
|
|
an output-only client does not link with the IM code, and an input-only
|
|
client does not link with the OM code. Locale modules can be loaded
|
|
on demand if the platform supports dynamic loading.<tt> </tt>
|
|
<dt>Transport Layer<dd>
|
|
There are several kinds of transports for connection between the IM
|
|
library and the IM Server. The IM Protocol is independent of a
|
|
specific transport layer protocol, and the sample implementation has a
|
|
mechanism to permit an IM Server to define the transports which the
|
|
IM Server is willing to use. The sample implementation supports
|
|
transport over the X protocol, TCP/IP and DECnet.<tt> </tt>
|
|
</dl>
|
|
<p>
|
|
There are IM Servers for Japanese and for Korean, internationalized
|
|
clients using IM services, and an IM Server developer's kit in
|
|
contrib. The IM Server developer's kit hides the details of the IM
|
|
Protocol and the transport layer protocols, and hides the differences
|
|
between the R5 and R6 protocols from the IM Server developer, so that
|
|
an IM developer has an easier task in developing new IM Servers.<tt> </tt>
|
|
|
|
<h2><a name="section46">4.7.</a> <tt> </tt>X Logical Font Description
|
|
<a name="toc46"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
The X Logical Font Description has been enhanced to include general 2D
|
|
linear transformations, character set subsets, and support for
|
|
polymorphic fonts.<tt> </tt>
|
|
See <b>xc/doc/specs/XLFD/xlfd.tbl.ms</b> for details.<tt> </tt>
|
|
|
|
<h2><a name="section47">4.8.</a> <tt> </tt>SYNC extension
|
|
<a name="toc47"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
The Synchronization extension lets clients synchronize via the X server.<tt> </tt>
|
|
This eliminates the network delays and the differences in synchronization
|
|
primitives between operating systems. The extension provides a general
|
|
Counter resource; clients can alter the value of a Counter, and can block
|
|
their execution until a Counter reaches a specific threshold. Thus, for
|
|
example, two clients can share a Counter initialized to zero, one client can
|
|
draw some graphics and then increment the Counter, and the other client can
|
|
block until the Counter reaches a value of one and then draw some additional
|
|
graphics.<tt> </tt>
|
|
|
|
<h2><a name="section48">4.9.</a> <tt> </tt>BIG-REQUESTS extension
|
|
<a name="toc48"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
The standard X protocol only allows requests up to
|
|
2^18
|
|
bytes long.<tt> </tt>
|
|
A new protocol extension, BIG-REQUESTS, has been added that allows a
|
|
client to extend the length field in protocol requests to be a 32-bit
|
|
value. This useful for PEX and other extensions that transmit complex
|
|
information to the server.<tt> </tt>
|
|
|
|
<h2><a name="section49">4.10.</a> <tt> </tt>XC-MISC extension
|
|
<a name="toc49"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
A new extension, XC-MISC, allows clients to get back ID ranges from the
|
|
server. Xlib handles this automatically under the covers. This is useful for
|
|
long-running applications that use many IDs over their lifetime.<tt> </tt>
|
|
|
|
<h2><a name="section50">4.11.</a> <tt> </tt>XTEST extension
|
|
<a name="toc50"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
The XTEST extension, which first shipped as a patch to Release 5, is included.<tt> </tt>
|
|
|
|
<h2><a name="section51">4.12.</a> <tt> </tt>Tree Reorganization
|
|
<a name="toc51"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
Many of the directories under <b>xc/</b> (renamed from <b>mit/</b>) have
|
|
been moved.<tt> </tt>
|
|
See the section <b>The XC Tree</b> for the new layout.<tt> </tt>
|
|
The reorganization has simplified
|
|
dependencies in the build process.<tt> </tt>
|
|
Once you get used to the new
|
|
layout, things will be easier to find.<tt> </tt>
|
|
<p>
|
|
Various filenames have been changed to minimize name conflicts on
|
|
systems
|
|
that limit file names to eight characters, a period, and three more
|
|
characters. Conflicts remain for various header (.h) files.<tt> </tt>
|
|
|
|
<h2><a name="section52">4.13.</a> <tt> </tt>Configuration Files
|
|
<a name="toc52"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
The configuration files have changed quite a bit, we hope in a mostly
|
|
compatible fashion. The main config files are now in
|
|
<b>xc/config/cf</b>, imake sources are in <b>xc/config/imake</b>, and
|
|
makedepend sources are in <b>xc/config/makedepend</b>. The <i>lndir</i>
|
|
program (for creating link trees) is in <b>xc/config/util</b>; there is
|
|
a <b>Makefile.ini</b> in that directory that may be useful to get
|
|
<i>lndir</i> built the first time (before you build the rest of the
|
|
tree).<tt> </tt>
|
|
<p>
|
|
The rules for building libraries have changed a lot; it is now much easier
|
|
to add a new library to the system.<tt> </tt>
|
|
<p>
|
|
The selection of <i>vendor</i><b>.cf</b> file has moved from
|
|
<b>Imake.tmpl</b> to a new <b>Imake.cf</b>.<tt> </tt>
|
|
<p>
|
|
The config variable that was called ServerOSDefines in R5 has been renamed
|
|
to ServerExtraDefines, and applies globally to all X server sources. The
|
|
variable ServerOSDefines now applies just to the os directory of the server.<tt> </tt>
|
|
<p>
|
|
There are a number of new config
|
|
variables dealing with C++, all of which have ``Cplusplus'' in their names.<tt> </tt>
|
|
<p>
|
|
``#'' should no longer be thought of as a valid comment character in
|
|
Imakefiles; use ``XCOMM'' instead.<tt> </tt>
|
|
<p>
|
|
There are new variables (e.g., HasPoll, HasBSD44Sockets,
|
|
ThreadedX) and rules (SpecialCObjectRule).<tt> </tt>
|
|
Read <b>xc/config/cf/README</b> for details.<tt> </tt>
|
|
<p>
|
|
The way libraries get built has changed: the unshared library .o's are now
|
|
placed in a subdirectory rather than the shared library .o's.<tt> </tt>
|
|
<p>
|
|
Multi-threaded programs can often just include <b>Threads.tmpl</b> in their
|
|
<b>Imakefile</b> to get the correct compile-time defines and libraries.<tt> </tt>
|
|
|
|
<h2><a name="section53">4.14.</a> <tt> </tt>Kerberos
|
|
<a name="toc53"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
There is a new authorization scheme for X clients, MIT-KERBEROS-5. It
|
|
implements MIT's Kerberos Version 5 user-to-user authentication. See
|
|
the <i>Xsecurity</i> manual page for details on how Kerberos works in X.<tt> </tt>
|
|
As with any other authentication protocol, <i>xdm</i> sets it up at
|
|
login time, and Xlib uses it to authenticate the client to the X server.<tt> </tt>
|
|
<p>
|
|
If you have Kerberos 5 on your system, set the HasKrb5 config variable
|
|
in <b>site.def</b> to YES to enable Kerberos support.<tt> </tt>
|
|
|
|
<h2><a name="section54">4.15.</a> <tt> </tt>X Transport Library (xtrans)
|
|
<a name="toc54"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
The X Transport Library is intended to combine all system and transport
|
|
specific code into a single place in the source tree. This API should be used
|
|
by all libraries, clients and servers of the X Window System.<tt> </tt>
|
|
Note that this API is <i>not</i> an X Consortium standard;
|
|
it is merely in internal part of our implementation.<tt> </tt>
|
|
Use of this API
|
|
should allow the addition of new types of transports and support for new
|
|
platforms without making any changes to the source except in the X Transport
|
|
Interface code.<tt> </tt>
|
|
<p>
|
|
The following areas have been updated to use xtrans:
|
|
<dl><dt><dd>
|
|
<pre>
|
|
lib/X11 (including the Input Method code)
|
|
lib/ICE
|
|
lib/font/fc
|
|
lib/FS
|
|
XServer/os
|
|
xfs/os
|
|
</pre>
|
|
</dl>
|
|
<p>
|
|
The XDMCP code in xdm and the X server has not been modified to use xtrans.<tt> </tt>
|
|
<p>
|
|
No testing has been done for DECnet.<tt> </tt>
|
|
|
|
<h2><a name="section55">4.16.</a> <tt> </tt>Xlib
|
|
<a name="toc55"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
Xlib now supports multi-threaded access to a single display
|
|
connection. Xlib functions lock the display structure, causing other
|
|
threads calling Xlib functions to be suspended until the first thread
|
|
unlocks. Threads inside Xlib waiting to read to or write from the X
|
|
server do not keep the display locked, so for example a thread hanging
|
|
on XNextEvent will not prevent other threads from doing output to the
|
|
server.<tt> </tt>
|
|
<p>
|
|
Multi-threaded Xlib runs on SunOS 5.3, DEC
|
|
OSF/1 1.3, Mach 2.5 Vers 2.00.1, AIX 2.3, and Microsoft Windows NT 3.1.<tt> </tt>
|
|
Locking for Xcms and I18N support has not been reviewed. A version
|
|
of ico that can be compiled to use threads is in <b>contrib/programs/ico</b>.<tt> </tt>
|
|
<p>
|
|
The Display and GC structures have been made opaque to normal application
|
|
code; references to private fields will get compiler errors. You can work
|
|
around some of these by compiling with -DXLIB_ILLEGAL_ACCESS, but better to
|
|
fix the offending code.<tt> </tt>
|
|
<p>
|
|
The Xlib implementation has been changed to support a form of
|
|
asynchronous replies, meaning that a request can be sent off to the
|
|
server, and then other requests can be generated without
|
|
waiting for the first reply to come back. This is used to advantage in two
|
|
new functions, XInternAtoms and XGetAtomNames, which reduce what would
|
|
otherwise require multiple round trips to the server down to a single round
|
|
trip. It is also used in some existing functions, such as
|
|
XGetWindowAttributes, to reduce two round trips to just one.<tt> </tt>
|
|
<p>
|
|
Lots of Xlib source files were renamed to fit better on systems
|
|
with short filenames.<tt> </tt>
|
|
The ``X'' prefix was dropped from most file names, and ``CIE'' and
|
|
``TekHVC'' prefixes were dropped.<tt> </tt>
|
|
<p>
|
|
Support for using poll() rather than select() is implemented, selected by the
|
|
HasPoll config option.<tt> </tt>
|
|
<p>
|
|
The BIG-REQUESTS extension is supported.<tt> </tt>
|
|
<p>
|
|
The following Xlib functions are new in Release 6:
|
|
<dl><dt><dd>
|
|
<pre>
|
|
XInternAtoms, XGetAtomNames
|
|
XExtendedMaxRequestSize
|
|
XInitImage
|
|
XReadBitmapFileData
|
|
IsPrivateKeypadKey
|
|
XConvertCase
|
|
XAddConnectionWatch, XRemoveConnectionWatch, XProcessInternalConnection
|
|
XInternalConnectionNumbers
|
|
XInitThreads, XLockDisplay, XUnlockDisplay
|
|
|
|
XOpenOM, XCloseOM
|
|
XSetOMValues, XGetOMValues
|
|
XDisplayOfOM, XLocaleOfOM
|
|
XCreateOC, XDestroyOC
|
|
XOMOfOC
|
|
XSetOCValues, XGetOCValues
|
|
XDirectionalDependentDrawing, XContextualDrawing
|
|
XRegisterIMInstantiateCallback, XUnregisterIMInstantiateCallback
|
|
XSetIMValues
|
|
|
|
XAllocIDs
|
|
XESetBeforeFlush
|
|
_XAllocTemp, _XFreeTemp
|
|
</pre>
|
|
</dl>
|
|
<p>
|
|
Support for MIT-KERBEROS-5 has been added.<tt> </tt>
|
|
|
|
<h2><a name="section56">4.17.</a> <tt> </tt>Internationalization
|
|
<a name="toc56"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
Internationalization (also known as I18N, there being 18 letters between the
|
|
<i>i</i> and <i>n</i>) of the X Window System,
|
|
which was originally introduced in
|
|
Release 5, has been significantly improved in R6. The R6 I18N architecture
|
|
follows that in R5, being based on the locale model used in ANSI C and POSIX,
|
|
with most of the I18N capability provided by Xlib. R5 introduced a
|
|
fundamental framework for internationalized input and output. It could enable
|
|
basic localization for left-to-right, non-context sensitive, 8-bit or
|
|
multi-byte codeset languages and cultural conventions. However, it did not
|
|
deal with all possible languages and cultural conventions. R6 also does not
|
|
cover all possible languages and cultural conventions, but R6 contains
|
|
substantial new Xlib interfaces to support I18N enhancements, in order to
|
|
enable additional language support and more practical localization.<tt> </tt>
|
|
<p>
|
|
The additional support is mainly in the area of text display. In order to
|
|
support multi-byte encodings, the concept of a FontSet was introduced in R5.<tt> </tt>
|
|
In R6, Xlib enhances this concept to a more generalized notion of output
|
|
methods and output contexts. Just as input methods and input contexts support
|
|
complex text input, output methods and output contexts support complex and
|
|
more intelligent text display, dealing not only with multiple fonts but also
|
|
with context dependencies. The result is a general framework to enable
|
|
bi-directional text and context sensitive text display.<tt> </tt>
|
|
|
|
<h2><a name="section57">4.18.</a> <tt> </tt>Xt
|
|
<a name="toc57"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
Support has been added for participation in session
|
|
management, with callbacks to application functionality in response to
|
|
messages from the session manager.<tt> </tt>
|
|
<p>
|
|
The entire library is now
|
|
thread-safe, allowing one thread at a time to enter the library and
|
|
protecting global data as necessary from concurrent use.<tt> </tt>
|
|
<p>
|
|
Support is
|
|
provided for registering event handlers for events generated by X
|
|
protocol extensions, and for dispatching those events to the
|
|
appropriate widget.<tt> </tt>
|
|
<p>
|
|
A mechanism has also been added for dispatching
|
|
events for non-widget drawables (such as pixmaps used within a widget)
|
|
to a widget.<tt> </tt>
|
|
<p>
|
|
Two new widget methods for instance allocation and
|
|
deallocation allow widgets to be treated as C++ objects in a C++
|
|
environment.<tt> </tt>
|
|
<p>
|
|
A new interface allows bundled changes to the managed set of children
|
|
of a Composite, reducing the visual disruption of multiple changes to
|
|
geometry layout.<tt> </tt>
|
|
<p>
|
|
Several new resources have been added to Shell
|
|
widgets, making the library compliant with the Release 6 ICCCM.<tt> </tt>
|
|
Parameterized targets of selections (new in Release 6) and the
|
|
MULTIPLE target are supported with new APIs.<tt> </tt>
|
|
<p>
|
|
Safe handling of POSIX
|
|
signals and other asynchronous notifications is now provided.<tt> </tt>
|
|
<p>
|
|
A hook
|
|
has been added to give notification of blocking in the event manager.<tt> </tt>
|
|
<p>
|
|
The client will be able to register callbacks on a per-display basis
|
|
for notification of a large variety of operations in the X Toolkit.<tt> </tt>
|
|
This feature is useful to external agents such as screen readers.<tt> </tt>
|
|
<p>
|
|
New String resource converters: XtStringToGravity and
|
|
XtCvtStringToRestartStyle.<tt> </tt>
|
|
<p>
|
|
The file search path
|
|
syntax has a new %D substitution that inserts
|
|
the default search path, making it easy
|
|
to prepend and append to the default search path.<tt> </tt>
|
|
<p>
|
|
The Xt implementation allows a configuration choice of poll or select for I/O
|
|
multiplexing, selectable at compile time by the HasPoll config option.<tt> </tt>
|
|
<p>
|
|
The Release 6 Xt implementation requires Release 6 Xlib.<tt> </tt>
|
|
Specifically, it uses the following new Xlib features:
|
|
XInternAtoms instead of multiple XInternAtom calls where possible,
|
|
input method support (Xlib internal connections), and
|
|
tests for the XVisibleHint in the flags of XWMHints.<tt> </tt>
|
|
<p>
|
|
When linking with Xt, you now need to also link with SMlib and ICElib. This
|
|
is automatic if you use the XTOOLLIB make variable or XawClientLibs <i>imake</i>
|
|
variable in your <b>Imakefiles</b>.<tt> </tt>
|
|
<p>
|
|
This implementation no longer allows NULL to be passed as the value in
|
|
the name/value pair in a request to XtGetValues. The default behavior
|
|
is to print the error message ``NULL ArgVal In XtGetValues'' and
|
|
exit. To restore the R5 behavior, set the config variable
|
|
<b>GetValuesBC</b> in <b>site.def</b>. The old behavior was never part
|
|
of the Xt specification, but some applications erroneously rely on it.<tt> </tt>
|
|
<p>
|
|
Motif 1.2 defines the types XtTypedArg and XtTypedArgList in VaSimpleP.h.<tt> </tt>
|
|
These types are now defined in IntrinsicP.h.<tt> </tt>
|
|
To work around the conflict, in Motif VaSimple.c, if IntrinsicP.h is
|
|
not already included before VaSimpleP.h, do so. In VaSimpleP.h, fence
|
|
off the type declarations with #if (XT_REVISION < 6) and #endif.<tt> </tt>
|
|
<p>
|
|
See Chapter 13 of the Xt specification for more details.<tt> </tt>
|
|
|
|
<h2><a name="section58">4.19.</a> <tt> </tt>Xaw
|
|
<a name="toc58"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
Some minor bugs have been fixed. Please note that the Athena Widgets have
|
|
been and continue to be low on our priority list; therefore many bugs remain
|
|
and many requests for enhancements have not been implemented.<tt> </tt>
|
|
<p>
|
|
Text and Panner widget translations have been augmented to include keypad
|
|
cursor keysyms in addition to the normal cursor keysyms.<tt> </tt>
|
|
<p>
|
|
The Clock, Logo, and Mailbox widgets have moved to their respective
|
|
applications.<tt> </tt>
|
|
<p>
|
|
Internationalization support is now included. Xaw uses native
|
|
widechar support when available, otherwise it uses the Xlib widechar routines.<tt> </tt>
|
|
Per system specifics are set in XawI18n.h.<tt> </tt>
|
|
<p>
|
|
The shared library major version number on SunOS 4 has been incremented
|
|
because of these changes.<tt> </tt>
|
|
|
|
<h2><a name="section59">4.19.1.</a> <tt> </tt>AsciiText
|
|
<a name="toc59"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
The name AsciiText is now a misnomer, but has been retained for backward
|
|
compatibility. A new resource, XtNinternational, has been added. If the
|
|
value of the XtNinternational resource is False (the default) AsciiSrc
|
|
and AsciiSink source and sink widgets are created, and the widget behaves
|
|
as it did for R5. If the value is True, MultiSrc and MultiSink source and
|
|
sink widgets are created. The MultiSrc widget will connect to an Input
|
|
Method Server if one is available, or if one isn't available, it will
|
|
use an Xlib internal pseudo input method that, at a minimum, does compose
|
|
processing. Application programmers who wish to use this feature will need
|
|
to add a call to XtSetLanguageProc to their programs.<tt> </tt>
|
|
<p>
|
|
The symbolic constant
|
|
FMT8BIT has been changed to XawFmt8Bit to be consistent with the new
|
|
symbolic constant XawFmtWide. FMT8BIT remains for backwards compatibility,
|
|
however its use is discouraged as it will eventually be removed from the
|
|
implementation. See the Xaw manual for details.<tt> </tt>
|
|
|
|
<h2><a name="section60">4.19.2.</a> <tt> </tt>Command, Label, List, MenuButton, Repeater, SmeBSB, and Toggle
|
|
<a name="toc60"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
Two new resources have been added, XtNinternational and XtNfontSet. If
|
|
XtNinternational is set to True the widget displays its text using the
|
|
specified fontset. See the Xaw manual for details.
|
|
|
|
<h2><a name="section61">4.20.</a> <tt> </tt>PEX
|
|
<a name="toc61"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
In discussing PEX it is important to understand the nature of 3D graphics
|
|
and the purpose of the existence of the PEX SI. The type of graphics for
|
|
which PEX provides support, while capable of being done in software, is
|
|
most commonly found in high performance hardware. Creation and maintenance
|
|
of software rendering code is costly and resource consumptive. The original
|
|
Sample Implementation for the PEX Protocol 5.0 was primarily intended for
|
|
consumption by vendors of the X Consortium who intended to provide PEX
|
|
products for sale. This implementation was intended to be fairly complete
|
|
however it was understood that vendors who intended to commercialize it
|
|
would dispose of portions of it, often fairly substantial ones. It was
|
|
therefore understood that functionality most likely to be disposed of by
|
|
them might be neglected in the development of a Sample Implementation.<tt> </tt>
|
|
As PEX is now a fairly mature standard distributed by most if not all major
|
|
vendors, and the standard itself has evolved from the 5.0 protocol level
|
|
to the 5.1 protocol level, the X Consortium and its supporting vendors have
|
|
recognized a need to focus on certain portions of the PEX technology while
|
|
deemphasizing others.<tt> </tt>
|
|
<p>
|
|
This release incorporates PEX functionality based upon the PEX 5.1
|
|
level protocol. The PEX Sample Implementation (SI) is composed of
|
|
several parts. The major components are the extension to the X
|
|
Server, which implements the PEX 5.1 protocol, and the client side
|
|
API, which provides a mechanism by
|
|
which clients can generate PEX protocol.<tt> </tt>
|
|
<p>
|
|
The API now provided with the PEX-SI is called PEXlib. This is a
|
|
change from R5 which shipped an API based upon the ISO IS PHIGS and
|
|
PHIGS PLUS Bindings. That API has been moved to contrib
|
|
in favor of the PEXlib API based upon the PEXlib 5.1
|
|
binding, which itself is an X Consortium standard. The PEXlib binding
|
|
is a lower-level interface than the previous PHIGS binding was and
|
|
maps more closely to the PEX protocol itself. It supports immediate
|
|
mode rendering functionality as well as the previous PHIGS workstation
|
|
modes and is therefore suited to a wider range of applications. It is
|
|
also suited for the development of higher level APIs. There are in
|
|
fact commercial implementations of the PHIGS API which utilize the
|
|
PEXlib API.<tt> </tt>
|
|
<p>
|
|
The PHIGS API based verification tool called InsPEX is moved to contrib.<tt> </tt>
|
|
A prototype of a possible new tool called
|
|
suspex is in the directory <b>contrib/test/suspex</b>. Suspex is PEXlib based.<tt> </tt>
|
|
<p>
|
|
Demo programs are no longer supported and have moved to contrib.<tt> </tt>
|
|
|
|
<h2><a name="section62">4.20.1.</a> <tt> </tt>PEX Standards and Functionality
|
|
<a name="toc62"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
This release conforms to the PEX Protocol Specification 5.1 though it
|
|
does not implement all the functionality specified therein.<tt> </tt>
|
|
<p>
|
|
The release comes with 2 fonts, Roman and Roman_M (see the <i>User's
|
|
Guide</i> for more details).<tt> </tt>
|
|
<p>
|
|
As discussed briefly above certain functionality is not implemented in this
|
|
Sample Implementation. Most notably Hidden Line, Hidden Surface Removal is
|
|
not implemented. This is a result of both architectural decisions and the
|
|
fact that it surely would have been replaced by vendors with proprietary
|
|
code. A contributed implementation which supports some of the HLHSR
|
|
functionality utilizing a Z buffer based technique is available for ftp
|
|
from ftp.x.org in the directory contrib/PEX_HLHSR.<tt> </tt>
|
|
<p>
|
|
This release does not support monochrome displays, though it does support 8
|
|
bit and 24 bit color.
|
|
<p>
|
|
Other functionality not complete in this release is:
|
|
<dl><dt><dd>
|
|
<pre>
|
|
Backface Attributes and Distinguish Flag
|
|
Font sharing between clients
|
|
Patterns, Hatches and associated attributes
|
|
Transparency
|
|
Depth Cueing for Markers
|
|
</pre>
|
|
</dl>
|
|
<p>
|
|
Double Buffering is available for the PHIGS Workstation subsets directly
|
|
through the workstation. The buffer mode should be set on when creating the
|
|
workstation. For immediate mode users double buffering is achieved via the
|
|
Multi Buffering Extension (aka MBX) found in the directory <b>xc/lib/Xext</b>.<tt> </tt>
|
|
<p>
|
|
PEX 5.1 protocol adds certain functionality to the Server extension,
|
|
accessible directly via the PEXlib API. This functionality includes
|
|
Picking via the Immediate Mode Renderer (Render Elements and
|
|
Accumulate State commands in Chapter 6, all of Chapter 7); new Escape
|
|
requests to allow vendors to support optional functionality; a Match
|
|
Rendering Targets request to return information about visuals, depth
|
|
and drawables the server can support; a noop Output command;
|
|
Hierarchical HLHSR control (i.e., during traversals); and renderer
|
|
clearing controls are the most important features.<tt> </tt>
|
|
|
|
<h2><a name="section63">4.21.</a> <tt> </tt>Header Files
|
|
<a name="toc63"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
Two new macros are defined in <b>Xos.h</b>: X_GETTIMEOFDAY and strerror.<tt> </tt>
|
|
X_GETTIMEOFDAY is like gettimeofday() but takes one argument on all
|
|
systems. strerror is defined only on systems that don't already have it.<tt> </tt>
|
|
<p>
|
|
A new header file <b>Xthreads.h</b> provides a platform-independent
|
|
interface to threads functions on various systems.<tt> </tt>
|
|
Include it instead of the system threads header file. Use the macros
|
|
defined in it instead of the system threads functions.<tt> </tt>
|
|
|
|
|
|
<h2><a name="section64">4.22.</a> <tt> </tt>Fonts
|
|
<a name="toc64"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
There are three new Chinese bdf fonts in <b>xc/fonts/bdf/misc</b>
|
|
(<b>gb16fs.bdf</b>, <b>gb16st.bdf</b>, <b>gb24st.bdf</b>).<tt> </tt>
|
|
<p>
|
|
Bitmap Charter fonts that are identical to the output generated from
|
|
the outline font have been moved to
|
|
<b>xc/fonts/bdf/unnec_</b>{<b>75</b>,<b>100</b>}<b>dpi</b>.<tt> </tt>
|
|
<p>
|
|
The Type 1 fonts contributed by Bitstream, IBM, and Adobe that shipped
|
|
in contrib in Release 5 have been moved into the core.<tt> </tt>
|
|
<p>
|
|
Some of the <b>misc</b> fonts, mostly in the <i>Clean</i> family, have
|
|
only the ASCII characters, but were
|
|
incorrectly labeled ``ISO8859-1''. These fonts have been renamed to
|
|
be ``ISO646.1991-IRV''. Aliases have been provided for the Release
|
|
5 names.<tt> </tt>
|
|
<p>
|
|
The <b>9x15</b> font has new shapes for some characters. The
|
|
<b>6x10</b> font has the entire ISO 8859-1 character set.<tt> </tt>
|
|
|
|
<h2><a name="section65">4.23.</a> <tt> </tt>Font library
|
|
<a name="toc65"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
The Type1 rasterizer that shipped in contrib in Release 5 is now part
|
|
of the core.<tt> </tt>
|
|
<p>
|
|
There is an
|
|
option to have the X server request glyphs only as it needs them.<tt> </tt>
|
|
The X server then caches the glyphs for future use.<tt> </tt>
|
|
<p>
|
|
Aliases in a <b>fonts.alias</b> file can allow one scalable alias name to
|
|
match all instances of another font. The ``!'' character introduces
|
|
a comment line in <b>fonts.alias</b> files.<tt> </tt>
|
|
<p>
|
|
A sample font authorization protocol, ``hp-hostname-1'' has been added.<tt> </tt>
|
|
It is
|
|
based on host names and is non-authenticating. The client requesting
|
|
a font from a font server provides (or passes through from its client)
|
|
the host name of the ultimate client of the font. There is no check
|
|
that this host name is accurate, as this is a sample protocol only.<tt> </tt>
|
|
<p>
|
|
The Speedo rasterizer can now read fonts with retail encryption.<tt> </tt>
|
|
This means that fonts bought over-the-counter at a computer store can
|
|
be used by the font server and X server.<tt> </tt>
|
|
<p>
|
|
Many, many bugs have been fixed.<tt> </tt>
|
|
|
|
<h2><a name="section66">4.24.</a> <tt> </tt>Font server
|
|
<a name="toc66"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
The font server has been renamed from <i>fs</i> to <i>xfs</i> to avoid
|
|
confusion with an AFS program. The default port has changed from 7000
|
|
(used by AFS) to 7100 and has been registered with the Internet
|
|
Assigned Numbers Authority.<tt> </tt>
|
|
<p>
|
|
The font server now implements a new major protocol version, version 2.<tt> </tt>
|
|
This change was made only to correct errors in the implementation of
|
|
version 1. Version 1 is still accepted by <i>xfs</i>.<tt> </tt>
|
|
<p>
|
|
You can now connect to <i>xfs</i> using the <b>local/</b> transport.<tt> </tt>
|
|
<p>
|
|
Many, many bugs have been fixed.<tt> </tt>
|
|
|
|
<h2><a name="section67">4.25.</a> <tt> </tt>X server
|
|
<a name="toc67"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
The server sources have moved to <b>xc/programs/Xserver</b>.<tt> </tt>
|
|
Server-side extension code exists as subdirectories. The <b>ddx</b>
|
|
directory is gone; <b>mi</b>, <b>cfb</b>, and <b>mfb</b> are at the top
|
|
level, and a <b>hw</b> (hardware) subdirectory now exists for holding
|
|
vendor-specific ddx code. Note: the absence of a ddx directory does
|
|
not imply that the conceptual split between dix and ddx is gone.<tt> </tt>
|
|
<p>
|
|
Function prototypes have been added to header files in
|
|
<b>xc/programs/Xserver/include</b>, <b>cfb</b>, <b>mfb</b>, <b>mi</b>, and
|
|
<b>os</b>.<tt> </tt>
|
|
<p>
|
|
Support for pixmap privates has been added. It is turned off by default, but
|
|
can be activated by putting -DPIXPRIV in the ServerExtraDefines parameter in
|
|
your <i>vendor</i><b>.cf</b> file. See the porting layer document for details.<tt> </tt>
|
|
<p>
|
|
New screen functions, called primarily by code in window.c, have been added to
|
|
make life easier for vendors with multi-layered framebuffers. Several
|
|
functions and some pieces of functions have moved from window.c to miwindow.c.<tt> </tt>
|
|
See the porting layer document for details. Also, the contents of union
|
|
_Validate (validate.h) are now device dependent; mivalidate.h contains a
|
|
sample definition.<tt> </tt>
|
|
<p>
|
|
An implementation of the SYNC extension is in
|
|
<b>xc/programs/Xserver/Xext/sync.c</b>.<tt> </tt>
|
|
As part of this work, client priorities
|
|
have also been implemented; see the tail end of WaitForSomething() in
|
|
WaitFor.c. The priority scheme is <i>strict</i> in that the client(s)
|
|
with the highest priority always runs. <i>twm</i> has been modified to
|
|
provide simple facilities for setting client priorities.<tt> </tt>
|
|
<p>
|
|
The server can now fetch font glyphs on demand instead of loading them
|
|
all at once. See <b>xc/programs/Xserver/dix/dixfonts.c</b>,
|
|
<b>xc/lib/font/fc/fserve.c</b>, and <b>xc/lib/font/fc/fsconvert.c</b>. A new
|
|
X server command line option, <b>-deferglyphs</b>, controls which types of
|
|
fonts (8 vs. 16 bit) to demand load; see the X manual page for details.<tt> </tt>
|
|
<p>
|
|
The os layer now uses sigaction on POSIX systems; a new function OsSignal was
|
|
added for convenience, which you should use in your ddx code.<tt> </tt>
|
|
<p>
|
|
A new timer interface has been added to the os layer; see the functions in
|
|
os/WaitFor.c. This interface is used by XKB, but we haven't tried to use it
|
|
anywhere else (such as Xext/sleepuntil.c) yet.<tt> </tt>
|
|
<p>
|
|
Redundant code for GC funcs was moved from cfbgc.c and mfbgc.c to migc.c.<tt> </tt>
|
|
This file also contains a few utility functions such as miComputeCompositeClip,
|
|
which replaces the chunk of code that used to appear near the top of most
|
|
versions of ValidateGC.<tt> </tt>
|
|
<p>
|
|
The cfb code can now be compiled multiple times to provide support for
|
|
multiple depths in the same server, e.g., 8, 12, and 24.<tt> </tt>
|
|
See <b>Imakefile</b> and
|
|
<b>cfb/cfbmskbits.h</b> under the <b>xc/programs/Xserver/</b> directory
|
|
for starters.<tt> </tt>
|
|
<p>
|
|
The cfb and mfb code have been modified to perform 64 bit reads and writes of
|
|
the framebuffer on the Alpha AXP. These modifications should be usable on
|
|
other 64 bit architectures as well, though we have not tested it on any
|
|
others. There are a few hacks in dix, notably ProcPutImage and ProcGetImage,
|
|
to work around the fact that the protocol doesn't allow you to specify 64 bit
|
|
padding. Note that the server will still not run on a machine such as a Cray
|
|
that does not have a 32 bit data type.<tt> </tt>
|
|
<p>
|
|
For performance, all region operations are now invoked via macros which by
|
|
default make direct calls to the appropriate mi functions. You can
|
|
conditionally compile them to continue calling through the screen structure.<tt> </tt>
|
|
The following change was made throughout the server:
|
|
<dl><dt><dd>
|
|
<pre>
|
|
``(*pScreen->RegionOp)(...)'' changes to ``REGION_OP(pScreen, ...)''
|
|
</pre>
|
|
</dl>
|
|
<p>
|
|
Some of the trivial region ops have been inlined in the macros. For
|
|
compatibility, the region function pointers remain in the screen structure
|
|
even if the server is compiled to make direct calls to mi. See
|
|
include/regionstr.h.<tt> </tt>
|
|
<p>
|
|
A generic callback manager is included and can be used to add
|
|
notification-style hooks anywhere in the server. See dixutils.c. The
|
|
callback manager is now being used to provide notification of when the
|
|
server is grabbed/ungrabbed, when a client's state changes, and when
|
|
an event is sent to a client. The latter two are used by the RECORD
|
|
extension.<tt> </tt>
|
|
<p>
|
|
A new option has been added, <b>-config</b> <i>filename</i>. This lets
|
|
you put server options in a file. See <b>os/utils.c</b>.<tt> </tt>
|
|
<p>
|
|
Xtrans has been installed into the os layer. See os/connection.c, io.c, and
|
|
transport.c. As a result, the server now supports the many flavors of SVR4
|
|
local connections.<tt> </tt>
|
|
<p>
|
|
The client structure now has privates like windows, pixmaps, and GCs. See
|
|
include/dixstruct.h, dix/privates.c, and dispatch.c.<tt> </tt>
|
|
<p>
|
|
Thin line pixelization is now consistent across cfb, mfb, and mi. It
|
|
is also reversible, meaning the same pixels are touched when drawing
|
|
from point A to point B as are touched when drawing from point B to
|
|
point A. A new header file, miline.h, consolidates some miscellaneous
|
|
line drawing utilities that had previously been duplicated in a number
|
|
of places.<tt> </tt>
|
|
|
|
<h2><a name="section68">4.25.1.</a> <tt> </tt>Xnest
|
|
<a name="toc68"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
A new server, Xnest, uses Xlib to implement ddx rendering. See
|
|
xc/programs/Xserver/hw/xnest. Xnest lets you run an X server in a window on
|
|
another X server. Uses include testing dix and extensions, debugging client
|
|
protocol errors, debugging grabs, and testing interactive programs in a
|
|
hardware-starved environment.<tt> </tt>
|
|
|
|
<h2><a name="section69">4.25.2.</a> <tt> </tt>Xvfb
|
|
<a name="toc69"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
Another new server, Xvfb, uses cfb or mfb code to render into a
|
|
framebuffer that is allocated in virtual memory. See
|
|
<b>xc/programs/Xserver/hw/vfb</b>. The framebuffer can be allocated in
|
|
normal memory, shared memory, or as a memory mapped file. Xvfb's
|
|
screen is normally not visible; however, when allocated as a memory
|
|
mapped file, <i>xwd</i> can display the screen by specifying the framebuffer
|
|
file as its input.<tt> </tt>
|
|
|
|
<h2><a name="section70">4.25.3.</a> <tt> </tt>ddx
|
|
<a name="toc70"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
<dl>
|
|
<dt><b>Sun ddx</b><dd>
|
|
Expanded device probe table finds multiple frame buffers of the same
|
|
type. Expanded keymap tables provide support for European and Asian
|
|
keyboards. Added per-key autorepeat support. Considerable cleanup and
|
|
duplicate code eliminated. Deletion of SunView support. GX source code now
|
|
included.<tt> </tt>
|
|
<dt><b>HP ddx</b><dd>
|
|
cfb-based sources included as <b>xc/programs/Xserver/hw/hp</b>.<tt> </tt>
|
|
<dt><b>svga ddx</b><dd>
|
|
new svga ddx for SVR4 included as
|
|
<b>xc/programs/Xserver/hw/svga</b>.<tt> </tt>
|
|
<dt><b>xfree86 ddx</b><dd>
|
|
ddxen from XFree86, Inc. included as
|
|
<b>xc/programs/Xserver/hw/xfree86</b>.<tt> </tt>
|
|
<dt><b>Amoeba ddx</b><dd>
|
|
ddx for Sun server on the Amoeba operating system included
|
|
as <b>xc/programs/Xserver/hw/sunAmoeba</b>. The server will require
|
|
additional patches for this to be usable.<tt> </tt>
|
|
|
|
</dl>
|
|
<h2><a name="section71">4.26.</a> <tt> </tt>New Programs
|
|
<a name="toc71"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
<b>xc/config/util/mkshadow/</b>, a replacement for <i>lndir</i>.<tt> </tt>
|
|
|
|
<h2><a name="section72">4.27.</a> <tt> </tt>Old Software
|
|
<a name="toc72"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
We have dropped support for the following libraries and programs
|
|
and have moved them to <b>contrib</b>:
|
|
CLX library,
|
|
PHIGS library,
|
|
<i>MacFS</i>,
|
|
<i>auto_box</i>,
|
|
<i>beach_ball</i>,
|
|
<i>gpc</i>,
|
|
<i>ico</i>,
|
|
<i>listres</i>,
|
|
<i>maze</i>,
|
|
<i>puzzle</i>,
|
|
<i>showfont</i>,
|
|
<i>viewres</i>,
|
|
<i>xbiff</i>,
|
|
<i>xcalc</i>,
|
|
<i>xditview</i>,
|
|
<i>xedit</i>,
|
|
<i>xev</i>,
|
|
<i>xeyes</i>,
|
|
<i>xfontsel</i>,
|
|
<i>xgas</i>,
|
|
<i>xgc</i>,
|
|
<i>xload</i>,
|
|
<i>xman</i>, and
|
|
<i>xpr</i>.<tt> </tt>
|
|
|
|
<h2><a name="section73">4.28.</a> <tt> </tt>xhost
|
|
<a name="toc73"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
Two new families have been registered: LocalHost, for connections over a
|
|
non-network transport, and Krb5Principal, for Kerberos V5 principals.<tt> </tt>
|
|
<p>
|
|
To distinguish between different host families, a new xhost syntax
|
|
``family:name'' has been introduced. Names are as before; families are
|
|
as follows:
|
|
<dl><dt><dd>
|
|
<pre>
|
|
inet: Internet host
|
|
dnet: DECnet host
|
|
nis: Secure RPC network name
|
|
krb: Kerberos V5 principal
|
|
local: contains only one name, ``''
|
|
</pre>
|
|
</dl>
|
|
The old-style syntax for names is still supported when the name does not
|
|
contain a colon.<tt> </tt>
|
|
|
|
<h2><a name="section74">4.29.</a> <tt> </tt>xrdb
|
|
<a name="toc74"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
Many new symbols are defined to tell you what extensions and visual
|
|
classes are available.<tt> </tt>
|
|
|
|
<h2><a name="section75">4.30.</a> <tt> </tt>twm
|
|
<a name="toc75"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
An interface for setting client priorities with the Sync extension has been
|
|
added.<tt> </tt>
|
|
<p>
|
|
Many bugs have not been fixed yet.<tt> </tt>
|
|
|
|
<h2><a name="section76">4.31.</a> <tt> </tt>xdm
|
|
<a name="toc76"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
There is a new resource, <b>choiceTimeout</b>, that controls how long
|
|
to wait for a display to respond after the user has selected a host
|
|
from the chooser.<tt> </tt>
|
|
<p>
|
|
Support has been added for a modular, dynamically-loaded greeter
|
|
library. This feature allows different dynamic libraries to by loaded
|
|
by <i>xdm</i> at run-time to provide different login window interfaces
|
|
without access to the <i>xdm</i> sources. It works on DEC OSF/1 and SVR4.<tt> </tt>
|
|
The name of the greeter library is controlled by another new resource,
|
|
<b>greeterLib</b>.<tt> </tt>
|
|
<p>
|
|
When you log in via <i>xdm</i>, <i>xdm</i> will use your password to
|
|
obtain the initial Kerberos tickets and store them in a local
|
|
credentials cache file. The credentials cache is
|
|
destroyed when the session ends.<tt> </tt>
|
|
|
|
<h2><a name="section77">4.32.</a> <tt> </tt>xterm
|
|
<a name="toc77"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
Now supports a few escape sequences from HP terminals, such as memory
|
|
locking. See <b>xc/doc/specs/xterm/ctlseqs.ms</b> for details.<tt> </tt>
|
|
<p>
|
|
The <b>termcap</b> and <b>terminfo</b> files have been updated.<tt> </tt>
|
|
<p>
|
|
<b>ctlseqs.ms</b> has moved out of the xterm source directory into
|
|
<b>xc/doc/specs/xterm</b>.<tt> </tt>
|
|
<p>
|
|
The logging mis-feature of xterm is removed. This change first appeared as
|
|
a public patch to Release 5.<tt> </tt>
|
|
<p>
|
|
Many bugs have not been fixed yet.<tt> </tt>
|
|
|
|
<h2><a name="section78">4.33.</a> <tt> </tt>xset
|
|
<a name="toc78"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
The screen saver control option has two new sub-options
|
|
to immediately activate or deactivate the screen saver:
|
|
<b>xset s activate</b> and <b>xset s reset</b>.<tt> </tt>
|
|
|
|
<h2><a name="section79">4.34.</a> <tt> </tt>X Test Suite
|
|
<a name="toc79"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
The X Test Suite, shipped separately from R5, is now part of the core
|
|
distribution in R6.<tt> </tt>
|
|
<p>
|
|
The code has been fixed to work on Alpha AXP. The Xi tests contributed by HP
|
|
and XIM tests contributed by Sun are integrated.<tt> </tt>
|
|
|
|
<h2><a name="section80">4.35.</a> <tt> </tt>Work in Progress
|
|
<a name="toc80"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
Everything under <b>xc/workInProgress</b> represents a work in progress
|
|
of the X Consortium.<tt> </tt>
|
|
<p>
|
|
Fresco, Low Bandwidth X (LBX), the Record extension, and the X Keyboard
|
|
extension (Xkb, which logically belongs here but was too tightly coupled
|
|
into Xlib and the server to extract) are neither standards nor draft
|
|
standards, are known to need design and/or implementation work, are
|
|
still evolving, and will not be compatible with any final standard should
|
|
such a standard eventually be agreed upon.<tt> </tt>
|
|
We are making them available in early form in order
|
|
to gather broader experimentation and feedback from those willing to
|
|
invest the time and energy to help us produce better standards.<tt> </tt>
|
|
<p>
|
|
Any use of these interfaces in commercial products runs the risk of
|
|
later source and binary incompatibilities.<tt> </tt>
|
|
|
|
<h2><a name="section81">4.35.1.</a> <tt> </tt>Fresco
|
|
<a name="toc81"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
R6 includes the first sample implementation of Fresco, a user interface
|
|
system specified using CORBA IDL and implemented in C++. Fresco is not
|
|
yet a Consortium standard or draft standard, but is being distributed as
|
|
a work in progress to demonstrate our current directions and to gather
|
|
feedback on requirements for a Fresco standard.<tt> </tt>
|
|
<p>
|
|
The Fresco Sample Implementation has been integrated into the X11R6
|
|
build process, and will be built automatically if you have a C++
|
|
compiler available. Documentation on Fresco can be found in
|
|
<b>xc/doc/specs/Fresco</b>. The Fresco and Xtf libraries are found in
|
|
<b>xc/workInProgress/Fresco</b> and <b>xc/workInProgress/Xtf</b>,
|
|
respectively. There are some simple Fresco example programs in
|
|
<b>contrib/examples/Fresco</b>, and a number of related programs in
|
|
<b>contrib/programs</b>, including:
|
|
<dl>
|
|
<dt><b>ixx</b><dd>
|
|
An IDL to C++ translator
|
|
<dt><b>i2mif</b><dd>
|
|
A program to generate FrameMaker MIF documents from comments in an IDL
|
|
specification
|
|
<dt><b>fdraw</b><dd>
|
|
A simple Fresco drawing editor
|
|
<dt><b>dish</b><dd>
|
|
A TCL interpreter with hooks to Fresco
|
|
</dl>
|
|
<p>
|
|
Working Imakefiles are provided for all of the utilities and examples.<tt> </tt>
|
|
<p>
|
|
A demo program (dish) is included that shows how a scripting language (Tcl)
|
|
can rather easily be bound to Fresco through the CORBA dynamic invocation
|
|
mechanism. A copy of Tcl is included in <b>contrib/lib/tcl</b>.<tt> </tt>
|
|
<p>
|
|
To build Fresco you must define HasCplusplus in <b>site.def</b>; in
|
|
addition, you may have to set CplusplusCmd and/or
|
|
CplusplusDependIncludes to invoke the appropriate C++ compiler and
|
|
find the required header files during make depend. Finally, you
|
|
should check the <i>vendor</i><b>.cf</b> to see if there are any other
|
|
configuration variables you should set to provide information about
|
|
your C++ compiler.<tt> </tt>
|
|
<p>
|
|
Fresco requires a C++ compiler that implements version 3 of the C++ language
|
|
(as approximately defined by USL cfront version 3). While Fresco does
|
|
not currently use templates or exceptions, it does make extensive use
|
|
of nested types, which were inadequately supported in earlier versions of
|
|
the language.<tt> </tt>
|
|
<p>
|
|
Fresco has been built with the following platforms and C++ compilers:
|
|
<dl><dt><dd>
|
|
<pre>
|
|
SPARCstation SunOS 4.1.3 CenterLine C++
|
|
SPARCstation Solaris 2.3 CenterLine C++ (requires v2.0.6)
|
|
SPARCstation Solaris 2.3 SPARCCompiler C++ v4.0
|
|
HP 9000/700 HPUX 9.0.1 CenterLine C++
|
|
SGI Indy IRIX 5.2 SGI C++
|
|
IBM RS/6000 AIX 3.2.5 IBM xlC
|
|
Sony NEWS NEWSOS 6.0 Sony C++
|
|
</pre>
|
|
</dl>
|
|
<p>
|
|
Fresco has also been compiled on the DEC Alpha under OSF/1 version 2.0 using
|
|
a beta test version of DEC C++ 1.3. Fresco cannot be built with the Gnu C++
|
|
compiler (version 2.5.8 or earlier) due to bugs and limitations in g++.<tt> </tt>
|
|
<p>
|
|
Building Fresco with CenterLine C++ requires that you pass
|
|
the <b>-Xa</b> flag to the C++ compiler. Place the following lines
|
|
in your site.def:
|
|
<dl><dt><dd>
|
|
<pre>
|
|
#define HasCenterLineCplusplus YES
|
|
#define CplusplusOptions -Xa
|
|
</pre>
|
|
</dl>
|
|
If CC is not in your default search path, add this line to <b>site.def</b>:
|
|
<dl><dt><dd>
|
|
<pre>
|
|
#define CplusplusCmd <i>/path/to/your/CC</i>
|
|
</pre>
|
|
</dl>
|
|
<p>
|
|
If you are building under Solaris 2, you must use ObjectCenter
|
|
version 2.0.6 or later; the C++ compiler in ObjectCenter 2.0.4
|
|
will produce Fresco applications that dump core on startup.<tt> </tt>
|
|
<p>
|
|
Fresco does not yet build under Microsoft Windows/NT.<tt> </tt>
|
|
|
|
<h2><a name="section82">4.35.2.</a> <tt> </tt>XKB (X Keyboard Extension)
|
|
<a name="toc82"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
Support for XKB is not compiled in to Xlib by default.<tt> </tt>
|
|
It is compiled in the X server by default only on Sun and Omron Luna
|
|
machines.<tt> </tt>
|
|
You can compile it in by setting
|
|
<dl><dt><dd>
|
|
<pre>
|
|
#define BuildXKB YES /* for support in the X server */
|
|
#define BuildXKBLib YES /* for support in the X library */
|
|
</pre>
|
|
</dl>
|
|
in the file <b>xc/config/cf/site.def</b>. Note that enabling XKB in
|
|
the X server is a pervasive change; you need to clean the server and
|
|
rebuild everything if you change this option.<tt> </tt>
|
|
<p>
|
|
Turning on XKB in the X server usually requires changes to the vendor ddx
|
|
keyboard handling. There is currently support only in the Sun and
|
|
Omron ddx.<tt> </tt>
|
|
<p>
|
|
If you turn on <b>BuildXKBLib</b>, additional functions are added to
|
|
Xlib. Since the resulting library is non-standard, it is given a
|
|
different name: <b>libX11kb</b> instead of <b>libX11</b>. All Makefiles
|
|
produced by <i>imake</i> will use <b>-lX11kb</b> to link Xlib.<tt> </tt>
|
|
<p>
|
|
The library changes for XKB are known not to work on the Cray;
|
|
many other systems have been tested, including the Alpha AXP.<tt> </tt>
|
|
<p>
|
|
There are some XKB test programs in <b>contrib/test/Xkb</b>.<tt> </tt>
|
|
<p>
|
|
The XKB support in Xlib is still at an early stage of formal review
|
|
and could change. We expect some additions in an eventual standard,
|
|
but few changes to the interfaces provided in this implementation.<tt> </tt>
|
|
A working draft of the protocol is in <b>/xc/doc/specs/Xkb/</b>.<tt> </tt>
|
|
|
|
<h2><a name="section83">4.35.3.</a> <tt> </tt>LBX (Low Bandwidth X)
|
|
<a name="toc83"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
The X Consortium is working to define a standard for running X
|
|
applications over serial lines, wide area networks, and other slow
|
|
links. This effort, called Low Bandwidth X (LBX), aims to improve the
|
|
startup time, performance, and interactive feel of X applications run
|
|
over low bandwidth transports.<tt> </tt>
|
|
<p>
|
|
LBX does this by interposing a <i>pseudo-server</i> (called the <i>proxy</i>)
|
|
between the X clients and the X server. The proxy caches data flowing
|
|
between the server and the clients, merges the X protocol streams, and
|
|
compresses the data that is sent over the low bandwidth wire. The X
|
|
server at the other end uncompresses the data and splits it back out
|
|
into separate request streams. The target is to make
|
|
many X applications transparently usable over 9600 bps modems.<tt> </tt>
|
|
<p>
|
|
A snapshot of the code for this effort
|
|
is included in <b>xc/workInProgress/lbx/</b> for people to examine and begin
|
|
experimenting with. It contains the following features:
|
|
<ul>
|
|
<li>
|
|
LZW compression of the binary data stream. Since commercial use
|
|
of LZW requires licensing patented technology, we are also looking
|
|
for an unencumbered algorithm and implementation to provide as well.<tt> </tt>
|
|
<li>
|
|
Delta compression of X packets (representing packets as differences
|
|
from previously sent packets).<tt> </tt>
|
|
<li>
|
|
Re-encoding of some graphics requests (points, lines, segments,
|
|
rectangles, and arcs).<tt> </tt>
|
|
<li>
|
|
Motion event throttling (to keep from flooding the wire).<tt> </tt>
|
|
<li>
|
|
Caching of data in the proxy for large data objects that otherwise
|
|
would be transmitted over the wire multiple times (e.g., properties,
|
|
font metrics, keyboard mappings, connection startup data, etc.).<tt> </tt>
|
|
<li>
|
|
Short-circuiting of requests for constant data (e.g., atoms,
|
|
colorname/rgb mappings, and read-only color cells).<tt> </tt>
|
|
</ul>
|
|
<p>
|
|
However, the following items have yet to be implemented (which is why it
|
|
isn't a standard yet):
|
|
<ul>
|
|
<li>
|
|
Re-encoding of a number of requests (e.g., QueryFont), events, etc.<tt> </tt>
|
|
<li>
|
|
Support for BIG-REQUESTS extension.<tt> </tt>
|
|
<li>
|
|
A non-networked serial protocol for environments which cannot
|
|
support os-level networking over serial lines.<tt> </tt>
|
|
<li>
|
|
A full specification needs to be written describing the network
|
|
protocol used between the proxy and the server.<tt> </tt>
|
|
</ul>
|
|
<p>
|
|
The X Consortium is continuing to work on both the implementation of the
|
|
remaining items and the full specification. The goal is to have all of the
|
|
pieces ready for public review later this year. Since the
|
|
specification for LBX <i>will</i> change,
|
|
we strongly recommend against anyone incorporating LBX into a product
|
|
based on this prototype. But, they are encouraged to start looking
|
|
at the code, examining the concepts, and providing feedback on its design.<tt> </tt>
|
|
|
|
<h2><a name="section84">4.35.4.</a> <tt> </tt>RECORD extension
|
|
<a name="toc84"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
RECORD is an X protocol extension that supports the recording of all
|
|
core X protocol and arbitrary X extension protocol.<tt> </tt>
|
|
<p>
|
|
A version of the extension is included in <b>xc/workInProgress/record</b>.<tt> </tt>
|
|
The implementation does not quite match the version 1.2 draft
|
|
specification, but the spec is going to change anyway; the version 1.3
|
|
draft is in <b>xc/doc/specs/Xext/record.ms</b>.<tt> </tt>
|
|
The GetConfig request is not fully implemented.<tt> </tt>
|
|
A test program is in <b>contrib/test/record</b>.<tt> </tt>
|
|
|
|
<h2><a name="section85">4.35.5.</a> <tt> </tt>Simple Session Manager
|
|
<a name="toc85"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
A simple session manager has been developed to test the new Session Management
|
|
protocol.<tt> </tt>
|
|
At the moment, it does not exercise the complete XSMP protocol and the user
|
|
interface is rather simple.<tt> </tt>
|
|
While it does have enough functionality to make it
|
|
useful, it needs more work before we would want
|
|
people to depend on it or use it as a good example of how to implement
|
|
the session protocol.<tt> </tt>
|
|
<ul>
|
|
<li>
|
|
Handles accepting connections from clients
|
|
<li>
|
|
Handles graceful or unexpected termination of clients
|
|
<li>
|
|
Maintains database of all properties set by clients
|
|
<li>
|
|
User interface provides a way to issue checkpoint and shutdown
|
|
messages to clients
|
|
<li>
|
|
Manages client interaction with the user
|
|
<li>
|
|
Can restart clients. Clients running on remote machines
|
|
are handled using the new <i>rstart</i> protocol.<tt> </tt>
|
|
<li>
|
|
Requires MIT-MAGIC-COOKIE-1 authentication from clients.<tt> </tt>
|
|
</ul>
|
|
<p>
|
|
We have not yet written a proxy for
|
|
connecting ICCCM 1.0 clients to the session manager.<tt> </tt>
|
|
<p>
|
|
A sample client, <i>xsmclient</i>, has been written to demonstrate the
|
|
session support in Xt.<tt> </tt>
|
|
|
|
<h2><a name="section86">4.35.6.</a> <tt> </tt>Multi-Threaded X Server
|
|
<a name="toc86"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
An attempt has been made to merge the multi-threaded server source
|
|
with the single-threaded source. The result is in the
|
|
<b>xc/workInProgress/MTXserver</b> directory.<tt> </tt>
|
|
The sources here include only files that
|
|
were changed from the single-threaded server.<tt> </tt>
|
|
The multi-threaded server may not compile.<tt> </tt>
|
|
Unfortunately, the
|
|
single-threaded server sources have continued to evolve since this
|
|
snapshot of the MTXserver was produced, so there is work to be done to
|
|
get the MTXserver sources back into a state where they can be compiled.<tt> </tt>
|
|
|
|
<h2><a name="section87">4.36.</a> <tt> </tt>ANSIfication
|
|
<a name="toc87"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
We've changed our sources to stop using the BSD function names index, rindex,
|
|
bcopy, bcmp; we now use strchr, strrchr, memcpy/memmove, and memcmp. We still
|
|
use the name bzero (because there is no BSD equivalent for the general case of
|
|
memset) but it is translated to memset via a #define in <X11/Xfuncs.h>. The
|
|
BSD function names are still supported in <X11/Xos.h> and <X11/Xfuncs.h>.<tt> </tt>
|
|
<p>
|
|
Most client-side uses of caddr_t should now be gone from our sources.<tt> </tt>
|
|
<p>
|
|
Explicit declarations of errno are now only used on
|
|
non-ANSI systems.<tt> </tt>
|
|
<p>
|
|
The libraries use more standard POSIX *_t types.<tt> </tt>
|
|
|
|
<h2><a name="section88">4.37.</a> <tt> </tt>Miscellaneous
|
|
<a name="toc88"> </a>
|
|
</h2>
|
|
<p>
|
|
|
|
A new version of the <i>patch</i> program is in <b>xc/util/patch</b>; it
|
|
understands the unified diff format produced by GNU <i>diff</i>.<tt> </tt>
|
|
|
|
<p><hr>
|
|
Markup created by <em>unroff</em> 1.0, <tt> </tt> <tt> </tt>March 21, 1996, <tt> </tt> <tt> </tt>net@informatik.uni-bremen.de</body>
|
|
</html>
|