RFC1013 日本語訳

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

Scheiflerがコメントのために要求するワーキンググループロバートW.をネットワークでつないでください: 1013 1987年6月

                  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.

Xウィンドウシステムプロトコル、バージョン11アルファーUpdate1987年4月のCopyright(c)1986、1987年のマサチューセッツ工科大学Xウィンドウシステムはマサチューセッツ工科大学の商標です。

Status of this Memo

この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).

このRFCは情報だけのためにインターネットコミュニティに分配されます。 それはインターネット標準を確立しません。 Xウィンドウシステムは、広く見直されて、テストされました。 インターネット共同体がそれを実験するよう奨励されます。 このメモの分配は無制限です(2ページの版権情報を見てください)。

M.I.T.                                                          [Page 1]

RFC 1013                                                       June 1987

マサチューセッツ工科大学[1ページ]RFC1013 1987年6月

   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

以下を書いてください。 ロバートW.Scheiflerコンピュータ科学研究所545技術正方形、部屋418ケンブリッジ(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)

貢献者: デーヴCarver(デジタルHPW)Branko Gerovac(デジタルHPW)ジムGettys(MIT/プロジェクトアティナ、Digital)フィルKarlton(デジタルWSL)スコット・マクレガー(デジタルSSG)・Ramラオ(デジタルUEG)デヴィッドRosenthal(Sun)デーヴ・ウィンチェル(デジタルUEG)

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

役に立つ入力を提供した初期のサーバの作成者: スーザン・Angebranndtの(デジタル)のレイモンドDrewry(デジタル)トッド・ニューマン(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)

役に立った状態で提供した招待された評論家が以下を入力します。 アンドリューCherenson(バークレー)はフィッシャー・(デジタル)のダン・ガーフィンケル(hp)・Leo Hourvitz(次)のBrockクリザン(hp)・デヴィッド・レイドロー・(星)のデーヴMellinger(Interleaf)ロンニューマン(MIT)ジョンOusterhout(バークレー)アンドリュー・パレー(ITC米カーネギーメロン大学)ラルフSwick(MIT)クレイグ・テイラー(Sun)ジェフェリーVroomを燃やします。(星)です。

   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.

このドキュメントが、原理を提供するのを試みないか、またはプラグマティックスがプロトコルを完全に理解しているか、またはバランスよく完全なシステムの中にそれを置くのが必要です。 確かに、Xバージョン10に関する知識はこのドキュメントを理解する際に支援されるでしょう。

M.I.T.                                                          [Page 2]

RFC 1013                                                       June 1987

マサチューセッツ工科大学[2ページ]RFC1013 1987年6月

   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.

このドキュメントは、正確な書式かビットencodingsを定義するのを試みません。

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

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

M.I.T.                                                          [Page 3]

RFC 1013                                                       June 1987

マサチューセッツ工科大学[3ページ]RFC1013 1987年6月

   SECTION 1.  TERMINOLOGY

セクション1。 用語

   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.

アクセスコントロールリストXはクライアントプログラムが動かされるかもしれないホストのリストを維持します。 デフォルトで、ローカル・ホストの上のプログラムだけがディスプレイを使用するかもしれません、そして、初期のリストで指定されたどんなホストもサーバで読みます。ローカル・ホストの上のクライアントはこの「アクセスコントロールリスト」を変えることができます。 また、いくつかのサーバ実装が、他の承認がメカニズムであると実装するかもしれません。

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

指針かキーボードが実際にクライアントをつかむシングルによって所有されているとき、活発なグラブAグラブは「アクティブです」。

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

先祖If WがAの目下である、そして、AはWの「先祖」です。

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

原子An「原子」はストリング名に対応するユニークなイドです。 原子は、特性、タイプ、および選択を特定するのに使用されます。

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

店Whenを支持して、サーバは窓のコンテンツを維持して、オフスクリーン保存している画素は「支援店」として知られています。

   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".

噛み付いている重力When aウィンドウはリサイズされて、窓の内容は必ず捨てられるというわけではありません。 窓の何らかの領域に前のコンテンツを移動させるようサーバ(保証を全くしませんが)に要求するのは可能です。 窓のいくらかの位置への窓のコンテンツのこのアトラクションは「噛み付いている重力」として知られています。

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

ビットマップA「ビットマップ」は深さ1のpixmapです。

   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.

指針でButtonsをつかむボタンはクライアントによって受け身に「つかまれるかもしれません」。 ボタンが押されると、指針はクライアントによって活発につかまれます。

   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.

バイトオーダーForイメージ(pixmap/ビットマップ)データ、バイトオーダーはサーバによって定義されます、そして、異なったネイティブのバイト順をもっているクライアントは必要に応じてバイトを交換しなければなりません。 プロトコルの他のすべての部分に関しては、バイトオーダーはクライアントによって定義されます、そして、サーバは必要に応じてバイトを交換します。

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

aの「子供」が窓を付ける子供はその最初に、レベルの「副-窓」です。

M.I.T.                                                          [Page 4]

RFC 1013                                                       June 1987

マサチューセッツ工科大学[4ページ]RFC1013 1987年6月

   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.

クライアントAnアプリケーション・プログラムは何らかのプロセス間通信(IPC)経路のそばでウィンドウシステムサーバに接続します、TCP接続や共有メモリバッファのように。 このプログラムはウィンドウシステムサーバです。より正確に、クライアントはIPC経路自体です。 サーバに開かれている複数の経路があるプログラムは複数のクライアントとしてプロトコルによって見なされます。 リソース寿命は生涯をプログラムするのではなく、コネクション存続期間までに制御されます。

   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".

窓の特定の領域に出力されて、制限するために長方形のグラフィックス文脈、ビットマップまたはリストを指定できる領域Inを切り取ります。 ビットマップか長方形によって定義されたイメージは「切り取り領域」と呼ばれます。

   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.

カラーマップにおける色のセルAnエントリーは「カラーセル」として知られています。 エントリーは赤くて、緑色の、そして、青い強度を指定する3つの値を含んでいます。 16が最小の強度であるゼロで符号のない数に噛み付いたので、これらの値はいつも見られます。 値はサーバによってスケーリングされて、ディスプレイハードウェアを合わせます。 セルの成分はDirectColorの他のセルとTrueColorカラーマップの成分があるコインシデンスです。

   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.

「カラーマップ」というカラーマップAは1セットのカラーセルから成ります。 ピクセル値は、表示するために強度を生産するためにカラー地図に索引をつけます。 ハードウェア制限によって、1つ以上のカラーマップがひところインストールされるかもしれません、それらの地図に関連している窓が正体と共に表示するように。

   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.

サーバとクライアントの間のIPC経路がプログラムする接続は「接続」として知られています。 クライアントプログラムには、要求とイベントが送られるサーバには1つの接続が通常あります(必ずない)。

   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.

窓が見えていて、窓の可視領域か目下のひとりの可視領域の中にカーソルのホットスポットがあるなら、封じ込めAの窓は指針を「含んでいます」。 窓の境界は封じ込めのための窓の一部として含まれています。 窓が指針を含んでいるなら、指針は“in"aの窓ですが、どんな目下も指針を含んでいません。

   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

座標系が発生源[0、0]が左上にある状態でX水平面とY垂直にするシステムを調整してください。 離散的であり、画素に関して座標。 各窓とpixmapはそうしました。

M.I.T.                                                          [Page 5]

RFC 1013                                                       June 1987

マサチューセッツ工科大学[5ページ]RFC1013 1987年6月

           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.

カーソルA「カーソル」はスクリーンの上の指針の目に見える形です。 それはホットスポット、ソースビットマップ、形のビットマップ、および1組の色から成ります。 pinterがその窓にあるとき、窓と定義されたカーソルは目に見える外観を制御します。

   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.

aの「深さ」徹底的な窓かpixmapが1それが持っている画素あたりのビットの数です。 gcontextの深さは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".

Keyboards(ネズミ)がメモするデバイス(トラックボール、などが一括してすべて知られているボタンの箱)は「デバイス」を入力しました。 コアプロトコルは2台のデバイス、「キーボード」、および「指針」に対処するだけです。

   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.

Drawable Bothの窓とpixmapsはソースと目的地としてグラフィック処理に使用されるかもしれません。 これらは"drawables"として一括して知られています。 しかしながら、ソースか目的地としてグラフィック処理にInputOnlyの窓を使用できません。

   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.

イベントClientsは「イベント」を通して情報において非同期に知識があります。 これらのイベントは、デバイスから非同期に生成されるか、またはクライアント要求の副作用として生成されるかもしれません。 イベントはタイプに分類されます。 クライアントが、そのタイプのイベントにおいて知識があるとspecificiallyに尋ねていない場合、サーバでイベントをクライアントに決して送りませんが、他のクライアントは他のクライアントにイベントを強制的に送らせることができます。 イベントは窓に比例して通常報告されます。

   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".

イベントマスクEventsは窓に比例して要求されています。 クライアントが窓に比例して要求するイベントタイプのセットは、「イベントマスク」を使用すると説明しました。

   Event sychronization
           There are certain race conditions possible when
           demultiplexing device events to clients (in particular
           deciding where pointer and keyboard events should be sent
           when in the middle of window management operations).  The
           event synchronization mechanism allows synchronous processing
           of device events.

クライアント(窓の管理操作の途中にあるとき、指針とキーボードイベントがどこに送られるべきであるかを特に決めます)への逆多重化デバイスイベントであるときに、イベントsychronization Thereは可能なある競合条件です。 イベントの同期化メカニズムはデバイスイベントの同期処理を許容します。

M.I.T.                                                          [Page 6]

RFC 1013                                                       June 1987

マサチューセッツ工科大学[6ページ]RFC1013 1987年6月

   Event propagation
           Device-related events "propagate" from the source window to
           ancestor windows until some client has expressed interest in
           handling that type of event, or until the event is discarded
           explicitly.

クライアントがそのタイプのイベントを扱うことへの関心を示したか、またはイベントが明らかに捨てられるとき、イベントの伝播のDevice関連のイベントはソースウィンドウから先祖の窓まで「伝播されます」。

   Event source
           The smallest window containing the pointer is the "source"
           of a device related event.

指針を含む最も小さいのが窓を付けるイベントソースはデバイスの「ソース」関連するイベントです。

   Exposure event
           Servers do not guarantee to preserve the contents of windows
           when windows are obscured or reconfigur contents of regions
           of windows have been lost.

暴露イベントServersは、窓が見えなくされるか、または窓の領域のreconfigur内容が失われたとき、窓のコンテンツを保存するのを保証しません。

   Extension
           Named "extensions" to the core protocol can be defined to
           extend the system.  Extension to output requests, resources,
           and event types are all possible, and expected.

システムを拡張するためにコアプロトコルへの拡大Named「拡大」を定義できます。 要求、リソース、およびイベントタイプを出力する拡大は、すべて可能で、予想されています。

   Font
           A "font" is an array of glyphs (typically characters).  The
           protocol does no translation or interpretation of character
           sets.  The client simply indicates values used to index the
           glyph array.  A font contains additional metric information
           to determine inter-glyph and inter-line spacing.

フォントA「フォント」はglyphs(通常キャラクタ)の配列です。 プロトコルは文字集合のどんな翻訳も解釈もしません。 クライアントは、値が以前はよくglyph配列に索引をつけていたのを単に示します。 フォントは相互glyphと相互系列スペースを決定する追加メートル法の情報を含んでいます。

   Glyph
           A "glyph" is an image, typically of a character, in a font.

Glyph A"glyph"は通常、フォントにおけるキャラクタのイメージです。

   Grab
           Keyboard keys, the keyboard, pointer buttons, the pointer,
           and the server can be "grabbed" for exclusive use by a
           client.  In general, these facilities are not intended to be
           used by normal applications, but are intended for various
           input and window managers to implement various styles of
           user interfaces.

クライアントは専用にグラブKeyboardキー、キーボード、指針ボタン、指針、およびサーバを「つかむことができます」。 一般に、これらの施設は、通常のアプリケーションで使用されることを意図しませんが、様々な入力とウィンドウマネージャが様々なスタイルのユーザインタフェースを実装することを意図します。

   Graphics context
           Various information for graphics output is stored in "GC"'s,
           such as foreground pixel, background pixel, line width,
           clipping region, etc.

グラフィックス出力のためのグラフィックス文脈Various情報は」の「GCものに保存されます、フォアグランド画素、バックグラウンド画素、線幅、切り取り領域などのように

   Hotspot
           A cursor has an associated "hot spot" which defines a point
           in the cursor that corresponds to the coordinates reported
           for the pointer.

ホットスポットAカーソルは指針のために報告された座標に対応するカーソルにポイントを定義する関連「ホットスポット」を持っています。

   Identifier
           Each resource has an "identifier", a unique value associated
           with it that clients use to name the resource.  An identifier

識別子Eachリソースには、「識別子」、クライアントがリソースを命名するのに使用するそれに関連しているユニークな値があります。 識別子

M.I.T.                                                          [Page 7]

RFC 1013                                                       June 1987

マサチューセッツ工科大学[7ページ]RFC1013 1987年6月

           can be used over any connection to name the resource.

リソースを命名するのにどんな接続の上でも使用できます。

   Inferiors
           The "inferiors" of a window are all of the subwindows nested
           below it: the children, the children's children, etc.

aの「目下」が窓を付ける目下は「副-窓」のすべてがそれの下で巣ごもったということです: 子供、子供の子供など

   Input focus
           The "input focus" is nominally where keyboard input goes.
           Keyboard events are by default sent to the client expressing
           interest on the window the pointer is in.  This is said to be
           a "real estate driven" input focus.  It is also possible to
           attach the keyboard input to a  specific window; events will
           then be sent to the appropriate client independent of the
           pointer position.

入力フォーカス、「入力フォーカス」は名目上はキーボード入力が行くところのそうです。 デフォルトで窓に上指針がある関心を示すクライアントにキーボードイベントを送ります。 これは「不動産駆動」の入力フォーカスであると言われています。 また、特定の窓にキーボード入力を付けるのも可能です。 そして、指針位置の如何にかかわらず適切なクライアントにイベントを送るでしょう。

   Input manager
           Control over keyboard input is typically provided by an
           "input manager" client.

キーボード入力の上の入力マネージャControlは「入力マネージャ」クライアントによって通常提供されます。

   InputOnly window
           A window that cannot be used for graphics requests.
           InputOnly windows are "invisible", and can be used to control
           such things as cursors, input event generation, and grabbing.

グラフィックス要求に使用できないInputOnlyウィンドウAの窓。 InputOnlyの窓は、「目に見えません」、カーソルのようなもの、入力イベント発生、およびつかむことを制御するのに使用できます。

   InputOutput window
           The "normal" kind of opaque window, used for both input
           and output.

窓の、そして、両方に、中古の不透明なものの「正常な」種類が入力したInputOutputの窓と出力。