Overview of the X Window System

The X Window System, or X, is a client-server, network-based windowing system developed at MIT (Massachusetts Institute of Technology) in 1984. Several versions of X have been developed. (X and X11 are used interchangeably throughout this chapter.)

X has been adopted as an industry-standard window system and is supported by the MIT X Consortium, which was formed in 1988. This consortium currently consists of over 65 companies, several universities, research organizations, and international vendors. The X Consortium is self-supporting

and was formed to promote cooperation within the computer industry in creating standard software interfaces at all layers in the X Window System environment.

The X Window System's architecture is based on the client-server model. The X server runs on a computer with a screen, keyboard, and pointing device (usually a mouse). Applications that run in the X environment are clients of the server. Clients can coexist on the computer with the server or they can be located on a remote system somewhere on the network.

Individual windows are controlled by a special client program, the window manager. The OpenWindows environment includes the olwm window manager. See "OPEN LOOK Window Manager" on page 6 and the olwm(1) man page for more information on the capabilities of olwm.

There are numerous books on all aspects of X and the X Window System. See the preface for a list of recommended books available through SunExpress and your local book store.

X Protocol

Clients and the server exchange information using a well-defined communication protocol--the X protocol--that forms the basis of the X Window System. Clients use the X protocol to send requests to the server to create and manipulate windows, to generate text and graphics, to receive input from the user, and to communicate with other client applications. The server uses the X protocol to send information back to clients in response to their requests and to deliver keyboard and other user input to the clients in the form of specialized data structures called events.

The X Library

The X protocol is implemented with a standard library of routines called Xlib, the X library. It provides you with a procedural interface that hides many of the low-level details of the X protocol, such as message formats. Various functions are also included that are not protocol-related, but important when building applications. The exact interface for this library may differ for each programming language. The OpenWindows development environment provides Xlib with a C programming language interface.

X Toolkits

X toolkits are one level up in terms of ease-of-use from the Xlib routines, just as the Xlib routines are one level up from the X protocol. Toolkits and higher-level graphics libraries can be implemented on top of Xlib and usually call Xlib directly.

The X protocol does not specify the look and feel of applications written for X nor how they should respond to user input. Although Xlib provides the foundation, write most of your applications using toolkits and graphics libraries that provide a consistent look and feel characteristic of a particular windowing system.

The X toolkits bundled with the OpenWindows product are XView and OLIT (OPEN LOOK Intrinsics Toolkit). See "OpenWindows Toolkits" on page 4 for more information.

X11 Features

The following libraries and applications, most of which are available from the MIT X Consortium, run on the OpenWindows server and are supported by Sun.

X11 Libraries

The X libraries are listed in the following table. The .so and .a files that comprise these libraries are located in /usr/openwin/lib.

Table 3-1

Library	Description	Available From MIT	Sun's Value Added
libX11	Xlib	Yes	MT Safe Dynamic loading of locale Search path includes /usr/openwin New keysyms
libXau	X Authorization library	Yes	None
libXaw	Athena Widget Set library	Yes	None
libXext	X Extensions library	Yes	Bug fixes, transparent overlays

Table 3-1

Library	Description	Available From MIT	Sun's Value Added
libXinput	Binary compatibility library for previous input extension	No	Sun library
libXi	Xinput Extension library	Yes	Bug fixes Supports OpenWindows X extensions
libXmu	X Miscellaneous Utilities library	Yes	Search path includes /usr/openwin
libXol	OLIT library	No (Available from USL)	Sun product--see the preface for a list of OLIT manuals
libXt	Xt Intrinsics library	Yes	Includes all private X Consortium patches as of 12/9/92
libxview	XView library	Yes	Sun product donated to X Consortium Bug fixes not included in MIT's X11R5 libxview

Supported X11 Applications

The OpenWindows environment includes the following client applications available from the MIT X Consortium:

• xterm....terminal emulator
• twm.....window manager
• xdm.....display manager
• bitmap...bitmap editor
• xfd.....font display utility
• xauth....access control program
• xhost....access control utility
• xrdb....resource control program
• xset....user preference setting program
• xsetroot..root window appearance setting utility
• xmodmap..keyboard control utility
• xlsfonts..server font listing utility
• xfontsel..font selection utility

• xlswins..window listing utility
• xwininfo..window information utility
• xlsclients client applications information utility
• xdpyinfo..server information display utility
• xprop....window and font properties utility

Unsupported Applications

The following are some applications and libraries, all of which are available from the MIT X Consortium, that run on the OpenWindows server but are not distributed or supported by Sun:

• Andrew, InterViews
• The uwm and wm window managers
• The CLX Common Lisp interface
• "contrib" MIT clients

ICCCM Compliance

OpenWindows is fully compliant in all areas of the ICCCM (Inter-Client Communication Conventions Manual). For more information on the ICCCM, see the X Protocol Reference Manual.

MIT X Extensions Supported

The OpenWindows server supports six X extensions as defined, or proposed by the MIT X Consortium. The server also includes OpenWindows-specific X extensions; however, they are not intended for use by client programs.

For more information on the standard X Extension mechanism, see The X Window System Server the Xlib Programming Manual.

The OpenWindows server supports the following MIT extensions:

• XInput
• MBX (Multi-Buffering)
• SHAPE
• MIT-SHM (Shared Memory)
• XTEST
• MIT-SUNDRY-NONSTANDARD

How To Access MIT X11 Extension Standards

The MIT X Consortium X11 standards referenced in the following sections are readily available to systems on Internet. The MIT X11 documentation resides in the /pub/R5untarred/mit/doc/extensions directory on the ftp.x.org machine. Use the File Transfer Program (ftp) to download files from this system. If you need help using ftp, refer to the ftp(1) man page. To determine if your system is connected to Internet, see your system administrator.

In the following sections the specification name for each extension is given, as well as the associated file name (on ftp.x.org) in parenthesis.

XInput Extension

The XInput Extension is Sun's implementation of the MIT X Consortium standard, X11 Input Extension Protocol Specification (/xinput/protocol.ms). This extension controls access to alternate input devices (that is, other than the keyboard and pointer). It allows client programs to select input from these devices independently from each other and independently from the core devices.

MBX (Multi-Buffering) Extension

The Multi-Buffering Extension is Sun's implementation of the MIT X Consortium proposed standard, Extending X for Double-Buffering, Multi-Buffering, and Stereo. This specification is located in /usr/openwin/share/src/extensions/mbx-spec-3.2.ps--it is not on the ftp.x.org machine. This extension provides the capability of creating and displaying multiple drawable buffers for each window, and displaying a rapid succession of buffers in a window to achieve smooth animation. The stereo windows portion is not implemented in Sun's Multi-Buffering Extension. See Appendix A, "Multi-Buffering Application Program Interface, Version 3.2" for more information.

---

Caution - In future releases, Sun's MBX implementation will change when this proposed standard is approved as an X Consortium standard. Backwards compatibility is not guaranteed.

---

SHAPE Extension

The SHAPE Extension is Sun's full implementation of the MIT X Consortium standard, X11 Nonrectangular Window Shape Extension (shape.ms). This extension provides the capability of creating arbitrary window and border shapes within the X11 protocol.

MIT-SHM (Shared Memory) Extension

The Shared Memory extension is Sun's full implementation of the MIT X Consortium experimental The MIT Shared Memory Extension (mit-shm.ms). This extension provides the capability to share memory XImages and pixmaps by storing the actual image data in shared memory. This eliminates the need to move data through the Xlib interprocess communication channel; thus, for large images, system performance increases. This extension is useful only if the client application runs on the same machine as the server.

XTEST Extension

The XTEST extension is Sun's full implementation of the MIT X Consortium proposed standard, X11 Input Synthesis Extension Proposal (xtest1.mm). This extension provides the capability for a client to generate user input and to control user input actions, without a user being present. This extension requires modification to the DDX layer of the server.

MIT-SUNDRY-NONSTANDARD

The MIT-SUNDRY-NONSTANDARD extension was developed at MIT and does not have a standard, or specification on the ftp.x.org machine. This extension handles miscellaneous erroneous protocol requests from X11R3 and earlier clients. It provides a request that turns the bug-compatibility mode on (handles certain erroneous requests) or off (returns an error for erroneous requests) and a request that gets the current state of the mode. This extension can be dynamically turned on or off with xset, or at server start up with openwin. See the xset(1) and openwin(1) man pages, specifically the -bc option, for more information.

Notes on X11 Programming

Common X11 programming issues are discussed below.

Compose Key Support

The OpenWindows version of Xlib supports Compose Key processing through calls to XLookupString.

---

x86 - On x86 keyboards, use the Ctrl-Shift-F1 key sequence for the Compose Key functionality.

---

Color Name Database

The color name database provides a mapping between ASCII color names and RGB color values. This mapping increases the portability of color programs and eases the programming task. Note that this mapping is subjective and has no objective scientific basis.

The source of the database is /usr/openwin/lib/X11/rgb.txt. This file is identical to the one provided in X11R5 from MIT. rgb.txt is compiled into the dbm(3) database files, rgb.dir and rgb.pag. When the server first starts up, it builds an internal representation of rgb.dir and rgb.pag used to map a color name to a color value.

X11 clients use XLookupColor or XAllocNamedColor to map a color name to a color value. The color name string passed to these routines is converted to lowercase before it is looked up in the database.

Color Recommendations

This section contains recommendations for programmers who intend to use the OpenWindows server color support facilities. Use these hints to maximize portability and color sharing:

• Do not rely on the locations of Black and White in the default PseudoColor colormap. Always use XAllocColor to allocate a pixel for rendering.

---

Note - It is important that programmers not rely on Black and White being in certain pixel locations. Future versions of the OpenWindows server and the servers of other vendors may have these colors located in different positions than the current server. For maximum portability and compatibility, X11 clients should always be written to use the XAllocColor function to allocate desired colors for rendering.

---

• Do not use a visual before you have checked on all supported visual types, using XGetVisualInfo or XMatchVisualInfo. Note that XGetVisualInfo is the recommended function to use because it has the ability to distinguish between visuals of the same class and depth.
• To reduce colormap flashing, it is usually a good policy to try to first allocate colors from the default colormap. Only when this allocation fails should you create a private colormap.
• For more hints on writing portable X11 color clients, see the "Hints for Windows Programming With Visuals" on page 57.