rfc1013.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                Robert W. Scheifler
Request for Comments: 1013                                     June 1987



                  X WINDOW SYSTEM PROTOCOL, VERSION 11
                                 Alpha Update
                                  April 1987
     Copyright (c) 1986, 1987 Massachusetts Institute of Technology
                   X Window System is a trademark of M.I.T.


Status of this Memo

   This RFC is distributed to the Internet community for information
   only.  It does not establish an Internet standard.  The X window
   system has been widely reviewed and tested.  The internet community
   is encouraged to experiment with it.  Distribution of this memo is
   unlimited (see copyright notice on page 2).



































M.I.T.                                                          [Page 1]

RFC 1013                                                       June 1987


   Permission to use, copy, modify, and distribute this document for any
   purpose and without fee is hereby granted, provided that the above
   copyright notice appear in all copies and that both that copyright
   notice and this permission notice are retained, and that the name of
   M.I.T. not be used in advertising or publicity pertaining to this
   document without specific, written prior permission.  M.I.T. makes no
   representations about the suitability of this document or the
   protocol defined in this document for any purpose.  It is provided
   "as is" without express or implied warranty.

    Author: Robert W. Scheifler
           Laboratory for Computer Science
           545 Technology Square, Room 418
           Cambridge, MA 02139

    Contributors:
           Dave Carver (Digital HPW)
           Branko Gerovac (Digital HPW)
           Jim Gettys (MIT/Project Athena, Digital)
           Phil Karlton (Digital WSL)
           Scott McGregor (Digital SSG)
           Ram Rao (Digital UEG)
           David Rosenthal (Sun)
           Dave Winchell (Digital UEG)

    Implementors of initial server who provided useful input:
           Susan Angebranndt (Digital)
           Raymond Drewry (Digital)
           Todd Newman (Digital)

    Invited reviewers who provided useful input:
           Andrew Cherenson (Berkeley)
           Burns Fisher (Digital)
           Dan Garfinkel (HP)
           Leo Hourvitz (Next)
           Brock Krizan (HP)
           David Laidlaw (Stellar)
           Dave Mellinger (Interleaf)
           Ron Newman (MIT)
           John Ousterhout (Berkeley)
           Andrew Palay (ITC CMU)
           Ralph Swick (MIT)
           Craig Taylor (Sun)
           Jeffery Vroom (Stellar)

   This document does not attempt to provide the rationale or pragmatics
   required to fully understand the protocol or to place it in
   perspective within a  complete system.  Knowledge of X Version 10
   will certainly aid in understanding this document.





M.I.T.                                                          [Page 2]

RFC 1013                                                       June 1987


   The protocol contains many management mechanisms that are not
   intended for normal applications.  Not all mechanisms are needed to
   build a particular user interface.  It is important to keep in mind
   that the protocol is intended to provide mechanism, not policy.

   This document does not attempt to define precise formats or bit
   encodings.

   -------------------------------------------------------------------













































M.I.T.                                                          [Page 3]

RFC 1013                                                       June 1987


   SECTION 1.  TERMINOLOGY


   Access control list
           X maintains a list of hosts from which client programs may be
           run.  By default, only programs on the local host may use the
           display, plus any hosts specified in an initial list read by
           the server.  This "access control list" can be changed by
           clients on the local host.  Some server implementations may
           also implement other authorization mechanisms.

   Active grab
           A grab is "active" when the pointer or keyboard is actually
           owned by the single grabbing client.

   Ancestors
           If W is an inferior of A, then A is an "ancestor" of W.

   Atom
           An "atom" is a unique id corresponding to a string name.
           Atoms are used to identify properties, types, and selections.

   Backing store
           When a server maintains the contents of a window, the
           off-screen saved pixels are known as a "backing store".

   Bit gravity
           When a window is resized, the contents of the window are
           not necessarily discarded.  It is possible to request the
           server (though no guarantees are made) to relocate the
           previous contents to some region of the window.  This
           attraction of window contents for some location of a window
           is known as "bit gravity".

   Bitmap
           A "bitmap" is a pixmap of depth one.

   Button grabbing
           Buttons on the pointer may be passively "grabbed" by a
           client.  When the button is pressed, the pointer is then
           actively grabbed by the client.

   Byte order
           For image (pixmap/bitmap) data, byte order is defined by
           the server, and clients with different native byte ordering
            must swap bytes as necessary.  For all other parts of the
           protocol, the byte order is defined by the client, and the
           server swaps bytes as necessary.

   Children
           The "children" of a window are its first-level subwindows.



M.I.T.                                                          [Page 4]

RFC 1013                                                       June 1987


   Client
           An application program connects to the window system server
           by some interprocess communication (IPC) path, such as a TCP
           connection or a shared memory buffer.  This program is the
           window system server.  More precisely, the client is the IPC
           path itself; a program with multiple paths open to the server
           is viewed as multiple clients by the protocol.  Resource
           lifetimes are controlled by connection lifetimes, not by
           program lifetimes.

   Clipping regions
           In a graphics context, a bitmap or list of rectangles can
           be specified to restrict output to a particular region of
           the window.  The image defined by the bitmap or rectangles
           is called a "clipping region".

   Color cell
           An entry in a colormap is known as a "color cell".  An entry
           contains three values specifying red, green and blue
           intensities.  These values are always viewed as 16 bit
           unsigned numbers, with zero being minimum intensity.  The
           values are scaled by the server to match the display
           hardware.  The components of a cell are coincident with
           components of other cells in DirectColor and TrueColor
           colormaps.

   Colormap
           A "colormap" consists of a set of color cells.  A pixel value
           indexes the color map to produce intensities to be displayed.
           Depending on hardware limitations, one or more colormaps may
           be installed at one time, such that windows associated with
           those maps display with true colors.

   Connection
           The IPC path between the server and client program is known
           as a "connection".  A client program typically (but not
           necessarily) has one connection to the server over which
           requests and events are sent.

   Containment
           A window "contains" the pointer if the window is viewable and
           the hotspot of the cursor is within a visible region of the
           window or a visible region of one of its inferiors.  The
           border of the window is included as part of the window for
           containment.  The pointer is "in" a window if the window
           contains the pointer but no inferior contains the pointer.

   Coordinate system
           The coordinate system has X horizontal and Y vertical, with
           the origin [0, 0] at the upper left.  Coordinates are
           discrete, and in terms of pixels.  Each window and pixmap has



M.I.T.                                                          [Page 5]

RFC 1013                                                       June 1987


           its own coordinate system.  For a window, the origin is at
           the inside upper left, inside the border.

   Cursor
           A "cursor" is the visible shape of the pointer on a screen.
           It consist of a hot spot, a source bitmap, a shape bitmap,
           and a pair of colors.  The cursor defined for a window
           controls the visible appearance when the pinter is in that
           window.

   Depth
           The "depth" of a window or pixmap is number of bits per pixel
           it has. The depth of a gcontext is the depth of the root of
           the gcontext.

   Device
           Keyboards, mice, tablets, track-balls, button boxes, etc. are
           all collectively known as input "devices".  The core protocol
           only deals with two devices, "the keyboard" and "the
           pointer".

   Drawable
           Both windows and pixmaps may be used as sources and
           destinations  in graphics operations.  These are collectively
           known as "drawables". However, an InputOnly window cannot be
           used as a source or destination in a graphics operation.

   Event
           Clients are informed of information asynchronously via
           "events". These events may be either asynchronously generated
           from devices, or generated as side effects of client
           requests.  Events are grouped into types; events are never
           sent to a client by the server unless the client has
           specificially asked to be informed of that type of event,
           but other clients can force events to be sent to other
           clients. Events are typically reported relative to a window.

   Event mask
           Events are requested relative to a window.  The set of event
           types a client requests relative to a window described using
           an "event mask".