4. Client to Window Manager Communication

To permit window managers to perform their role of mediating the competing demands for resources such as screen space, the clients being managed must adhere to certain conventions and must expect the window managers to do likewise. These conventions are covered here from the client's point of view.
ウィンドウマネージャにスクリーン・スペースのようなリソースの競合する要求を解決させる役割を実行させるために、 管理されているクライアントはある協定を厳守しなければならず、 ウィンドウマネージャが同様に実行することを期待しなければならない。 ここではこれらの協定をクライアントの視点から見る。

In general, these conventions are somewhat complex and will undoubtedly change as new window management paradigms are developed. Thus, there is a strong bias toward defining only those conventions that are essential and that apply generally to all window management paradigms. Clients designed to run with a particular window manager can easily define private protocols to add to these conventions, but they must be aware that their users may decide to run some other window manager no matter how much the designers of the private protocol are convinced that they have seen the "one true light" of user interfaces.
一般にこれらの協定は多少複雑で、 新しいウィンドウ管理パラダイムが開発されれば、都度確実に変化する。 したがって、 すべてのウィンドウ管理パラダイムに当てはまる、 一般的で不可欠な協定だけを定義する傾向が強くなる。 特別のウィンドウマネージャの影響下で実行されることを前提とした クライアントでは協定に加えるべきプライベート・プロトコルを定義することは 容易にできる。 しかし、プライベート・プロトコルの設計者がどれほど ユーザ・インターフェースの「1つの真実の光」を見たと確信しているとしても、 ユーザが他のウィンドウマネージャを実行すると決定してもよいことに 気づかなければならない。

It is a principle of these conventions that a general client should neither know nor care which window manager is running or, indeed, if one is running at all. The conventions do not support all client functions without a window manager running; for example, the concept of Iconic is not directly supported by clients. If no window manager is running, the concept of Iconic does not apply. A goal of the conventions is to make it possible to kill and restart window managers without loss of functionality.
任意のウィンドウマネージャが少しでも走っている場合、 一般的なクライアントはどのウィンドウマネージャが実行されているか、 知ることも注意することのするべきことではないことがこれらの協定の原則である。 協定はウィンドウマネージャを実行せずに、 すべてのクライアント機能を支援するとは限らない; 例えば Iconic の概念をクライアントが直接サポートすることはない。 ウィンドウマネージャが走っていない場合、 Iconic の概念は提供されない。 協定のゴールは機能を損なうことなく ウィンドウマネージャを停止／再起動ができるようにすることである。

Each window manager will implement a particular window management policy; the choice of an appropriate window management policy for the user's circumstances is not one for an individual client to make but will be made by the user or the user's system administrator. This does not exclude the possibility of writing clients that use a private protocol to restrict themselves to operating only under a specific window manager. Rather, it merely ensures that no claim of general utility is made for such programs.
個々のウィンドウマネージャは固有のウィンドウ管理ポリシーを インプリメントするであろう; ユーザの事情に合わせたウィンドウ管理ポリシーの選択は、 個々のクライアントが作るべきものではなく、 ユーザあるいはユーザのシステム管理者によってなされるであろう。 これは特定のウィンドウマネージャの下でのみ作動することに限定するために、 プライベート・プロトコルを使用するクライアントを書くことを除外しない。 そのようなプログラムにぴったり合った 一般的なユーティリィティに対する要求を単に保証するだけである。

For example, the claim is often made: "The client I'm writing is important, and it needs to be on top." Perhaps it is important when it is being run in earnest, and it should then be run under the control of a window manager that recognizes "important" windows through some private protocol and ensures that they are on top. However, imagine, for example, that the "important" client is being debugged. Then, ensuring that it is always on top is no longer the appropriate window management policy, and it should be run under a window manager that allows other windows (for example, the debugger) to appear on top.
例えば " 私が書いているクライアントは重要であり、それはトップ上にある必要がある。 " といった要求はしばしば出される。 恐らく実際に運用されている場合には重要であり、 その時にはプライベート・プロトコルを使って " 重要な " ウィンドウを認識し、 トップ上にあることを保証する、 ウィンドウマネージャの管理の下で実行されるべきである。 しかしながら、 例えば " 重要な " クライアントをデバッグしていることを想像してみて欲しい。 この時にはトップ上に常にあることを保証することは もはや適切なウィンドウ管理ポリシーではなく、 他のウィンドウ (例えばデバッガ) がトップに現われることを可能にするウィンドウマネージャの下で 実行されるべきである。

4.1. Client's Actions

In general, the object of the X Version 11 design is that clients should, as far as possible, do exactly what they would do in the absence of a window manager, except for the following:
一般論として、 Xバージョン11のオブジェクトの設計では、 下記の項目を除いて、 可能な限りクライアントは ウィンドウマネージャがない状態でも実行できることを 確実に行うべきである:

4.1.1. Creating a Top-Level Window

A client's top-level window is a window whose override-redirect attribute is False . It must either be a child of a root window, or it must have been a child of a root window immediately prior to having been reparented by the window manager. If the client reparents the window away from the root, the window is no longer a top-level window; but it can become a top-level window again if the client reparents it back to the root.
クライアントのトップレベル・ウィンドウは override-redirect 属性が False のウィンドウである。 それはルート・ウィンドウの子供であるか、 あるいはウィンドウマネージャによって reparent される直前までルート・ウィンドウの子供だったウィンドウである。 クライアントがウィンドウをルートから遠ざけて reparent する場合、 このウィンドウはトップレベルのウィンドウではない; しかしクライアントがルートにそれを reparent すれば、 再びトップレベルのウィンドウになることができる。

A client usually would expect to create its top-level windows as children of one or more of the root windows by using some boilerplate like the following:
クライアントは、 通常、 下記のような決まり文句を使い、 ルート・ウィンドウの1つ以上の子供として、 トップレベルのウィンドウを作成することを予想している: 


win = XCreateSimpleWindow(dpy, DefaultRootWindow(dpy), xsh.x, xsh.y,
	xsh.width, xsh.height, bw, bd, bg);

If a particular one of the root windows was required, however, it could use something like the following:
しかしながら、 もし特別なルート・ウィンドウが必要であれば、 下記のようなものを使用することができるだろう: 


win = XCreateSimpleWindow(dpy, RootWindow(dpy, screen), xsh.x, xsh.y,
	xsh.width, xsh.height, bw, bd, bg);

Ideally, it should be possible to override the choice of a root window and allow clients (including window managers) to treat a nonroot window as a pseudo-root. This would allow, for example, the testing of window managers and the use of application-specific window managers to control the subwindows owned by the members of a related suite of clients. Doing so properly requires an extension, the design of which is under study.
理想的には、 ルート・ウィンドウの選択を無視し、 (ウィンドウマネージャを含んだ)クライアントが ルートでないウィンドウを疑似的なルートとして扱うことを可能にするべきである。 例えば、 これはウィンドウマネージャの試験や、 クライアントに関連する一連のメンバーによって 所有されたサブウィンドウをコントロールする アプリケーション特有のウィンドウマネージャの利用を可能にするであろう。 その拡張は非常に適切に行うべきであり、 その設計は検討段階にある。

From the client's point of view, the window manager will regard its top-level window as being in one of three states:
クライアントの視点から見た場合、 ウィンドウマネージャはトップレベルのウィンドウを ３つの状態の１つであると評価するであろう:

Newly created windows start in the Withdrawn state. Transitions between states happen when the top-level window is mapped and unmapped and when the window manager receives certain messages. For further details, see sections 4.1.2.4 and 4.1.4.
新しく作成されたウィンドウは、 Withdrawn 状態でスタートする。 トップレベルのウィンドウがマップ／アンマップされた場合、 およびウィンドウマネージャが特定のメッセージを受け取る場合、 状態間の推移は起こる。 その他の詳細に関してはセクション 4.1.2.4 および 4.1.4 を参照せよ。

4.1.2. Client Properties

Once the client has one or more top-level windows, it should place properties on those windows to inform the window manager of the behavior that the client desires. Window managers will assume values they find convenient for any of these properties that are not supplied; clients that depend on particular values must explicitly supply them. The window manager will not change properties written by the client.
一旦クライアントが1つ以上のトップレベルのウィンドウを持てば、クライアントが望むと振る舞いのウィンドウマネージャに通知するために、それはそれらのウィンドウに特性を置くべきです。ウィンドウマネージャは、それらが供給されない特性のうちのどれにでも便利に感じる値を仮定する?ﾅしょう;特別の値に依存するクライアントは明示的にそれらを供給するに違いありません。ウィンドウマネージャは、クライアントによって書かれた特性を変更しないでしょう。

The window manager will examine the contents of these properties when the window makes the transition from the Withdrawn state and will monitor some properties for changes while the window is in the Iconic or Normal state. When the client changes one of these properties, it must use Replace mode to overwrite the entire property with new data; the window manager will retain no memory of the old value of the property. All fields of the property must be set to suitable values in a single Replace mode ChangeProperty request. This ensures that the full contents of the property will be available to a new window manager if the existing one crashes, if it is shut down and restarted, or if the session needs to be shut down and restarted by the session manager.
ウィンドウが内向的な状態で推移を作り、ウィンドウが像あるいは標準状態にある間に、変更のいくつかの特性をモニターするだろう場合、ウィンドウマネージャは、これらの特性の内容を調べるでしょう。 クライアントがこれらの特性のうちの1つを変更する場合、それは、新しいデータを備えた全特性に上書きするために上書きモードを使用しなければなりません;ウィンドウマネージャは、特性の古い値の記憶を保持しないでしょう。特性のフィールドはすべて単一の上書きモードChangePropertyリクエストで適切な値にセットされるに違いありません。 これは、既存のものが衝突する場合あるいはそれがシャット・ダウンされ再開される場合、あるいはセッション・マネージャーがセッションを閉鎖し再開する必要がある場合、特性の十分な内容が新しいウィンドウマネージャに利用可能だろうということを保証します。

Convention
慣例

Clients writing or rewriting window manager properties must ensure that the entire content of each property remains valid at all times.
ウィンドウマネージャ財産を書くか書き直すクライアントは、各財産の全内容がいつでも有効なままであることを保証するに違いありません。

Some of these properties may contain the IDs of resources, such as windows or pixmaps. Clients should ensure that these resources exist for at least as long as the window on which the property resides.
これらの特性のうちのいくつかは、ウィンドウまたはpixmapsのような資源のIDを含んでいるかもしれません。少なくとも特性が存在するウィンドウの間これらの資源が存在するクライアントは保証するべきです。

If these properties are longer than expected, clients should ignore the remainder of the property. Extending these properties is reserved to the X Consortium; private extensions to them are forbidden. Private additional communication between clients and window managers should take place using separate properties. The only exception to this rule is the WM_PROTOCOLS property, which may be of arbitrary length and which may contain atoms representing private protocols; see section 4.1.2.7.
これらの特性が期待されたより長い場合、クライアントは特性の残りを無視するべきです。これらの特性の拡張はXコンソーシアムだけに用いられます;それらに対する個人の拡張が禁止されます。クライアントとウィンドウマネージャの間の個人の付加的なコミュニケーションは特有財産を使用して起こるべきです。この規則のただ一つの例外はWM_PROTOCOLS特性(それらは任意の長さであるかもしれないし、それらは個人のプロトコルを表わす原子を含んでいるかもしれない)です; section 4.1.2.7参照。

The next sections describe each of the properties the clients need to set, in turn. They are summarized in the table in section 4.4.
次のセクションは、クライアントがセットする必要のある特性の各々について順番に記述します。それらはセクション4.4のテーブルの中で要約されます。

4.1.2.1. WM_NAME Property

The WM_NAME property is an uninterpreted string that the client wants the window manager to display in association with the window (for example, in a window headline bar).

The encoding used for this string (and all other uninterpreted string properties) is implied by the type of the property. The type atoms to be used for this purpose are described in section 2.7.1.

Window managers are expected to make an effort to display this information. Simply ignoring WM_NAME is not acceptable behavior. Clients can assume that at least the first part of this string is visible to the user and that if the information is not visible to the user, it is because the user has taken an explicit action to make it invisible.

On the other hand, there is no guarantee that the user can see the WM_NAME string even if the window manager supports window headlines. The user may have placed the headline off-screen or have covered it by other windows. WM_NAME should not be used for application-critical information or to announce asynchronous changes of an application's state that require timely user response. The expected uses are to permit the user to identify one of a number of instances of the same client and to provide the user with noncritical state information.

Even window managers that support headline bars will place some limit on the length of the WM_NAME string that can be visible; brevity here will pay dividends.

4.1.2.2. WM_ICON_NAME Property

The WM_ICON_NAME property is an uninterpreted string that the client wants to be displayed in association with the window when it is iconified (for example, in an icon label). In other respects, including the type, it is similar to WM_NAME. For obvious geometric reasons, fewer characters will normally be visible in WM_ICON_NAME than WM_NAME.

Clients should not attempt to display this string in their icon pixmaps or windows; rather, they should rely on the window manager to do so.

4.1.2.3. WM_NORMAL_HINTS Property

The type of the WM_NORMAL_HINTS property is WM_SIZE_HINTS. Its contents are as follows:
WM_NORMAL_HINTSプロパティのタイプはWM_SIZE_HINTSである。 その内容は以下のとおり:
Field Type Comments
flags CARD32 (see the next table)
pad 4*CARD32 For backwards compatibility
max_width INT32
max_height INT32
width_inc INT32
height_inc INT32
max_aspect (INT32,INT32)
base_width INT32 If missing, assume min_width
base_height INT32 If missing, assume min_height
win_gravity If missing, assume NorthWest

The WM_SIZE_HINTS.flags bit definitions are as follows:
WM_SIZE_HINTS.flagsビットの定義は以下のとおり:
Name Value Field
USPosition 1 User-specified x, y
USSize 2 User-specified width, height
PPosition 4 Program-specified position
PSize 8 Program-specified size
PMinSize 16 Program-specified minimum size
PMaxSize 32 Program-specified maximum size
PResizeInc 64 Program-specified resize increments
PAspect 128 Program-specified min and max aspect ratios
PBaseSize 256 Program-specified base size
PWinGravity 512 Program-specified window gravity

To indicate that the size and position of the window (when a transition from the Withdrawn state occurs) was specified by the user, the client should set the USPosition and USSize flags, which allow a window manager to know that the user specifically asked where the window should be placed or how the window should be sized and that further interaction is superfluous. To indicate that it was specified by the client without any user involvement, the client should set PPosition and PSize .
孤立した状態からの推移が発生した場合、 ユーザによって指定されたウィンドウのサイズおよび位置を示すために、 クライアントは USPosition と USSize のフラグをセットするべきである。 これによりウィンドウマネージャは どこでウィンドウを置かなければならないか、 ウィンドウをどのように分類しなければならないかなど ユーザが特に尋ねたことを知ることができ、 それ以上のやりとりが不必要であること 知ることができる。 ユーザ関与のないクライアントによってそれが指定されたことを示すために、 クライアントは PPosition と PSize をセットするべきである。

The size specifiers refer to the width and height of the client's window excluding borders.
サイズを指定したものはクライアントの境界を除く ウィンドウの幅および高さを参照する。

The win_gravity may be any of the values specified for WINGRAVITY in the core protocol except for Unmap : NorthWest (1), North (2), NorthEast (3), West (4), Center (5), East (6), SouthWest (7), South (8), and SouthEast (9). It specifies how and whether the client window wants to be shifted to make room for the window manager frame.
win_gravity は Unmap を除いてコア・プロトコルの中で WINGRAVITY のために指定された次の値のいずれかに違いない: NorthWest (1), North (2), NorthEast (3), West (4), Center (5), East (6), SouthWest (7), South (8), SouthEast ウィンドウマネージャのフレームに場所を空けるため、 クライアントのウィンドウをどこへ、 どのようにシフトするかを指定する。

If the win_gravity is Static , the window manager frame is positioned so that the inside border of the client window inside the frame is in the same position on the screen as it was when the client requested the transition from Withdrawn state. Other values of win_gravity specify a window reference point. For NorthWest , NorthEast , SouthWest , and SouthEast the reference point is the specified outer corner of the window (on the outside border edge). For North , South , East , and West the reference point is the center of the specified outer edge of the window border. For Center the reference point is the center of the window. The reference point of the window manager frame is placed at the location on the screen where the reference point of the client window was when the client requested the transition from Withdrawn state.
もし win_gravity が Static である場合、 フレームの内部のクライアント・ウィンドウの内部の境界は クライアントが 孤立状態 (Withdrawn state) から遷移するように要求された時とスクリーン上の同じ位置にあるように、 ウィンドウマネージャ・フレームは位置する。 win_gravity のその他の値はウィンドウの参照ポイントを示す。 NorthWest , NorthEast , SouthWest , SouthEast の場合、 参照ポイントはウィンドウの外側の角(境界の外縁)を示します。 North , South , East , West の場合、 参照ポイントはウィンドウ境界の外縁の中央を示す。 Center の場合、 参照ポイントはウィンドウの中央を示す。 ウィンドウマネージャのフレームの参照ポイントはクライアントウィンドウが 孤立状態 (Withdrawn state) から遷移するよう要求された時の参照ポイントがあった スクリーン上の位置にに置かれる。

The min_width and min_height elements specify the minimum size that the window can be for the client to be useful. The max_width and max_height elements specify the maximum size. The base_width and base_height elements in conjunction with width_inc and height_inc define an arithmetic progression of preferred window widths and heights for nonnegative integers i and j:
min_width／min_heightエレメントは クライアントにとって有用なウィンドウでありうる 最小サイズを指定する。 max_width／max_heightエレメントは最大サイズを指定する。 base_width／base_heightエレメントはwidth_inc／height_incと合わせて 正の整数 i および j による望ましいウィンドウの幅、高さの等差数列を定義します:

width = base_width + (i × width_inc)
height = base_height + (j × height_inc)

Window managers are encouraged to use i and j instead of width and height in reporting window sizes to users. If a base size is not provided, the minimum size is to be used in its place and vice versa.
ユーザにウィンドウ・サイズを報告する際に ウィンドウマネージャは 幅と高さの代わりに i と j を使用することを促される。 base size が提供されない場合 minimum size が、 あるいはその逆でも使用されることになっている。

The min_aspect and max_aspect fields are fractions with the numerator first and the denominator second, and they allow a client to specify the range of aspect ratios it prefers. Window managers that honor aspect ratios should take into account the base size in determining the preferred window size. If a base size is provided along with the aspect ratio fields, the base size should be subtracted from the window size prior to checking that the aspect ratio falls in range. If a base size is not provided, nothing should be subtracted from the window size. (The minimum size is not to be used in place of the base size for this purpose.)
min_aspect と max_aspect フィールドは 最初が分子、次が分母を表す分数であり、 クライアントが縦横比の範囲を指定することに使用される。 縦横比を考慮するウィンドウマネージャは、 好ましいウィンドウ・サイズを決定する際に base size を考慮に入れるべきである。 base size が縦横比フィールドと共に提示される場合、 base size は縦横比が範囲にあることをチェックする前に ウィンドウ・サイズから引かれるべきである。 しかし基礎サイズが提供されない場合、 何もウィンドウ・サイズから引かれてはならない。 minimum size はこの目的のための base size の代わりには使用しない。

4.1.2.4. WM_HINTS Property

The WM_HINTS property (whose type is WM_HINTS) is used to communicate to the window manager. It conveys the information the window manager needs other than the window geometry, which is available from the window itself; the constraints on that geometry, which is available from the WM_NORMAL_HINTS structure; and various strings, which need separate properties, such as WM_NAME. The contents of the properties are as follows:
WM_HINTS プロパティはウィンドウマネージャに通信するために使用される。 このプロパティは ウィンドウ自体から利用可能なウィンドウの形状 (window geometry)、 WM_NORMAL_HINTS 構造で利用可能で幾何学的情報、 WM_NAME のような個別のプロパティが必要とする様々なストリング 以外にウィンドウマネージャが必要とする情報を伝える。 プロパティの内容は以下のとおりである:
Field Type Comments
flags CARD32 (see the next table)
input CARD32 The client's input model
クライアントの input モデル
initial_state CARD32 The state when first mapped
最初にマップされた時の状態
icon_pixmap PIXMAP The pixmap for the icon image
アイコンイメージのピクスマップ
icon_window WINDOW The window for the icon image
アイコンイメージのウィンドウ
icon_x INT32 The icon location
icon_y INT32 アイコンの配置
icon_mask PIXMAP The mask for the icon shape
アイコン形状のマスク

The WM_HINTS.flags bit definitions are as follows:
WM_HINTS のフラグビットは次のように定義されている:
Name Value Field
InputHint 1 input
StateHint 2 initial_state
IconPixmapHint 4 icon_pixmap
IconWindowHint 8 icon_window
IconPositionHint 16 icon_x & icon_y
IconMaskHint 32 icon_mask
WindowGroupHint 64 window_group
MessageHint 128 (this bit is obsolete)
UrgencyHint 256 urgency

Window managers are free to assume convenient values for all fields of the WM_HINTS property if a window is mapped without one.
ウィンドウマネージャの助けなしにウィンドウがマップされる場合、 ウィンドウマネージャは WM_HINTS プロパティのすべてのフィールドに対して任意の値を自由に設定することができる。

The input field is used to communicate to the window manager the input focus model used by the client (see section 4.1.7).
入力フィールドはクライアントによって使用されている入力フォーカスモデルを ウィンドウマネージャに伝えるために使用される。 (セクション 4.1.7参照)

Clients with the Globally Active and No Input models should set the input flag to False . Clients with the Passive and Locally Active models should set the input flag to True .
全体的にアクティブでインプットモデルを持たないクライアントは input flag に False 設定するべきである。 受動的なクライアントあるいは局所的にアクティブなクライアントは input flag に True 設定するべきである。

From the client's point of view, the window manager will regard the client's top-level window as being in one of three states:
クライアントから見た場合、 ウィンドウマネージャはクライアントのトップレベルのウィンドウを 次の３つの状態のうちの１つとして見るだろう。

The semantics of these states are described in section 4.1.4. Newly created windows start in the Withdrawn state. Transitions between states happen when a top-level window is mapped and unmapped and when the window manager receives certain messages.
これらの状態の意味は セクション 4.1.4 で説明する。 新しく作成されたウィンドウは、 Withdrawn 状態でスタートする。 トップレベルのウィンドウがマップ／アンマップされた場合、 あるいはウィンドウマネージャがあるメッセージを受け取った場合、 状態の推移が起こる。

The value of the initial_state field determines the state the client wishes to be in at the time the top-level window is mapped from the Withdrawn state, as shown in the following table:
次のテーブルの中で示されるように、 initial_stateフィールドの値は トップレベルのウィンドウが Withdrawn 状態から マップされる時にクライアントが望む状態に決定される:
State Value Comments
NormalState 1 The window is visible
IconicState 3 The icon is visible

The icon_pixmap field may specify a pixmap to be used as an icon. This pixmap should be:
icon_pixmapフィールドにはアイコンとして使用される ピクスマップを指定されることもある。 このピクスマップは次の条件を満たしているべきである:

The icon_mask specifies which pixels of the icon_pixmap should be used as the icon, allowing for icons to appear nonrectangular.
アイコンとして使用されるべき icon_pixmap のピクセルを指定する icon_mask は外形が四角でないアイコンを可能にする。

The icon_window field is the ID of a window the client wants used as its icon. Most, but not all, window managers will support icon windows. Those that do not are likely to have a user interface in which small windows that behave like icons are completely inappropriate. Clients should not attempt to remedy the omission by working around it.
icon_window フィールドはクライアントがアイコンとして使用することを望むウィンドウのIDである。 全てではないが、 ほとんどのウィンドウマネージャはアイコン・ウィンドウをサポートしている。 アイコンとして使用することが不適当な小さなウィンドウへの ユーザーインターフェースにしてはならない。 クライアントはその回りの処理を省略するように試みてはならない。

Clients that need more capabilities from the icons than a simple two-color bitmap should use icon windows. Rules for clients that do are set out in section 4.1.9.
単純な２色ビットマップのアイコンより多くの能力を必要とするクライアントは アイコン・ウィンドウを使用するべきである。

The (icon_x,icon_y) coordinate is a hint to the window manager as to where it should position the icon. The policies of the window manager control the positioning of icons, so clients should not depend on attention being paid to this hint.
(icon_x,icon_y) の座標はアイコンを配置に関するウィンドウマネージャへのヒントである。 ウィンドウマネージャのポリシーはアイコンの位置をコントロールする。 したがってクライアントはこのヒントに依存してはならない。

The window_group field lets the client specify that this window belongs to a group of windows. An example is a single client manipulating multiple children of the root window.
window_groupフィールドは このウィンドウが特定のグループのウィンドウに属することを クライアントに明示させる。 例はルート・ウィンドウの多数の子供を操作する一つのクライアントである。

    Conventions

  1. The window_group field should be set to the ID of the group leader. The window group leader may be a window that exists only for that purpose; a placeholder group leader of this kind would never be mapped either by the client or by the window manager.
    window_group フィールドはグループ・リーダーのIDがセットされるべきである。 ウィンドウ・グループ・リーダーは その目的のためにのみ存在するウィンドウかもしれない。 この種の位置決め用のグループ・リーダーは クライアントあるいはウィンドウマネージャによってマップされることはない。
  2. The properties of the window group leader are those for the group as a whole (for example, the icon to be shown when the entire group is iconified).
    ウィンドウ・グループ・リーダーのプロパティはグループ全体に対するものである。 (例えば、全グループがアイコン化される時に示されるアイコン)

Window managers may provide facilities for manipulating the group as a whole. Clients, at present, have no way to operate on the group as a whole.
ウィンドウマネージャは、 グループ全体を操作するための機能を提供することもある。 現在、クライアントはグループ全体として作動する方法を持っていない。

The messages bit, if set in the flags field, indicates that the client is using an obsolete window manager communication protocol,11 rather than the WM_PROTOCOLS mechanism of section 4.1.2.7.
もしフラグ・フィールドのメッセージ・ビットがセットされれば、 クライアントが セクション 4.1.2.7 の WM_PROTOCOLS メカニズムではなく、 旧式のウィンドウマネージャ・コミュニケーション・プロトコルを 使用していることを示している。

The UrgencyHint flag, if set in the flags field, indicates that the client deems the window contents to be urgent, requiring the timely response of the user. The window manager must make some effort to draw the user's attention to this window while this flag is set. The window manager must also monitor the state of this flag for the entire time the window is in the Normal or Iconic state and must take appropriate action when the state of the flag changes. The flag is otherwise independent of the window's state; in particular, the window manager is not required to deiconify the window if the client sets the flag on an Iconic window. Clients must provide some means by which the user can cause the UrgencyHint flag to be set to zero or the window to be withdrawn. The user's action can either mitigate the actual condition that made the window urgent, or it can merely shut off the alarm.
もしフラグ・フィールドがセットされれば、 UrgencyHint フラグはクライアントがウィンドウ内容をユーザに適時のレスポンスを要求して 緊急であると考えることを示す。 ウィンドウマネージャはこのフラグがセットである間、 このウィンドウにユーザの注意を引き付けるための対処をする必要がある。 ウィンドウマネージャはさらにフラグの状態が変わった場合、 ウィンドウが Normal か Iconic の状態での適切な処置を行なうため、 常時このフラグの状態をモニターする必要がある。 一方、フラグはウィンドウの状態から独立している。 クライアントがアイコン化ウィンドウにフラグをセットした場合、 ウィンドウマネージャはアイコン化を解除することを特に要求されない。 クライアントは ユーザが UrgencyHint フラグに０をセットできる、あるいは withdrawn 状態のウィンドウを引き起こすことができる なんらかの手段を提供しなければならない。 ユーザのアクションは ウィンドウを緊急にした実際の条件を緩和することができるし、 アラームを止めることもできる。

Rationale

This mechanism is useful for alarm dialog boxes or reminder windows, in cases where mapping the window is not enough (e.g. in the presence of multi-workspace or virtual desktop window managers), and where using an override-redirect window is too intrusive. For example, the window manager may attract attention to an urgent window by adding an indicator to its title bar or its icon. Window managers may also take additional action for a window that is newly urgent, such as by flashing its icon (if the window is iconic) or by raising it to the top of the stack.
このメカニズムは ウィンドウのマッピングが十分でない (例えば、マルチ・ワークスペース・ウィンドウマネージャや 仮想デスクトップウィンドウマネージャが存在する場合)ようなケースや、 ウィンドウの override-redirect を使用し過ぎたケースで、 アラーム・ダイアログ・ボックスや注意ウィンドウに役立ちます。 例えば、ウィンドウマネージャは、 そのタイトル・バーあるいはそのアイコンに指標を加えることにより、 緊急のウィンドウに注意を引きつけることができる。 さらに、ウィンドウマネージャは新しく緊急のそのアイコン (ウィンドウがアイコン化されている場合に) を点滅させることによって、 あるいはスタックのトップへそれを上げることによって ウィンドウ用に補足処置を講ずるかもしれない。

4.1.2.5. WM_CLASS Property

The WM_CLASS property (of type STRING without control characters) contains two consecutive null-terminated strings. These specify the Instance and Class names to be used by both the client and the window manager for looking up resources for the application or as identifying information. This property must be present when the window leaves the Withdrawn state and may be changed only while the window is in the Withdrawn state. Window managers may examine the property only when they start up and when the window leaves the Withdrawn state, but there should be no need for a client to change its state dynamically.

The two strings, respectively, are:

Note that WM_CLASS strings are null-terminated and, thus, differ from the general conventions that STRING properties are null-separated. This inconsistency is necessary for backwards compatibility.

4.1.2.6. WM_TRANSIENT_FOR Property

The WM_TRANSIENT_FOR property (of type WINDOW) contains the ID of another top-level window. The implication is that this window is a pop-up on behalf of the named window, and window managers may decide not to decorate transient windows or may treat them differently in other ways. In particular, window managers should present newly mapped WM_TRANSIENT_FOR windows without requiring any user interaction, even if mapping top-level windows normally does require interaction. Dialogue boxes, for example, are an example of windows that should have WM_TRANSIENT_FOR set.

It is important not to confuse WM_TRANSIENT_FOR with override-redirect. WM_TRANSIENT_FOR should be used in those cases where the pointer is not grabbed while the window is mapped (in other words, if other windows are allowed to be active while the transient is up). If other windows must be prevented from processing input (for example, when implementing pop-up menus), use override-redirect and grab the pointer while the window is mapped.

4.1.2.7. WM_PROTOCOLS Property

The WM_PROTOCOLS property (of type ATOM) is a list of atoms. Each atom identifies a communication protocol between the client and the window manager in which the client is willing to participate. Atoms can identify both standard protocols and private protocols specific to individual window managers.

All the protocols in which a client can volunteer to take part involve the window manager sending the client a ClientMessage event and the client taking appropriate action. For details of the contents of the event, see section 4.2.8. In each case, the protocol transactions are initiated by the window manager.

The WM_PROTOCOLS property is not required. If it is not present, the client does not want to participate in any window manager protocols.

The X Consortium will maintain a registry of protocols to avoid collisions in the name space. The following table lists the protocols that have been defined to date.
Protocol Section Purpose
WM_TAKE_FOCUS 4.1.7 Assignment of input focus
WM_SAVE_YOURSELF Appendix C Save client state request (deprecated)
WM_DELETE_WINDOW 4.2.8.1 Request to delete top-level window
It is expected that this table will grow over time.

4.1.2.8. WM_COLORMAP_WINDOWS Property

The WM_COLORMAP_WINDOWS property (of type WINDOW) on a top-level window is a list of the IDs of windows that may need colormaps installed that differ from the colormap of the top-level window. The window manager will watch this list of windows for changes in their colormap attributes. The top-level window is always (implicitly or explicitly) on the watch list. For the details of this mechanism, see section 4.1.8.

4.1.2.9. WM_CLIENT_MACHINE Property

The client should set the WM_CLIENT_MACHINE property (of one of the TEXT types) to a string that forms the name of the machine running the client as seen from the machine running the server.

4.1.3. Window Manager Properties

The properties that were described in the previous section are those that the client is responsible for maintaining on its top-level windows. This section describes the properties that the window manager places on client's top-level windows and on the root.
前のセクションに記述されたプロパティはクライアントが そのトップレベルのウィンドウ上で維持する責任を負うものです。 このセクションではクライアントのトップレベルのウィンドウ、 あるいはルートにウィンドウマネージャが置くプロパティについて記述する。

4.1.3.1. WM_STATE Property

The window manager will place a WM_STATE property (of type WM_STATE) on each top-level client window that is not in the Withdrawn state. Top-level windows in the Withdrawn state may or may not have the WM_STATE property. Once the top-level window has been withdrawn, the client may re-use it for another purpose. Clients that do so should remove the WM_STATE property if it is still present.

Some clients (such as xprop) will ask the user to click over a window on which the program is to operate. Typically, the intent is for this to be a top-level window. To find a top-level window, clients should search the window hierarchy beneath the selected location for a window with the WM_STATE property. This search must be recursive in order to cover all window manager reparenting possibilities. If no window with a WM_STATE property is found, it is recommended that programs use a mapped child-of-root window if one is present beneath the selected location.

The contents of the WM_STATE property are defined as follows:
Field Type Comments
state CARD32 (see the next table)
icon WINDOW ID of icon window

The following table lists the WM_STATE.state values:
State Value
WithdrawnState 0
NormalState 1
IconicState 3

Adding other fields to this property is reserved to the X Consortium. Values for the state field other than those defined in the above table are reserved for use by X Consortium.

The state field describes the window manager's idea of the state the window is in, which may not match the client's idea as expressed in the initial_state field of the WM_HINTS property (for example, if the user has asked the window manager to iconify the window). If it is NormalState , the window manager believes the client should be animating its window. If it is IconicState , the client should animate its icon window. In either state, clients should be prepared to handle exposure events from either window.

When the window is withdrawn, the window manager will either change the state field's value to WithdrawnState or it will remove the WM_STATE property entirely.

The icon field should contain the window ID of the window that the window manager uses as the icon for the window on which this property is set. If no such window exists, the icon field should be None . Note that this window could be but is not necessarily the same window as the icon window that the client may have specified in its WM_HINTS property. The WM_STATE icon may be a window that the window manager has supplied and that contains the client's icon pixmap, or it may be an ancestor of the client's icon window.

4.1.3.2. WM_ICON_SIZE Property

A window manager that wishes to place constraints on the sizes of icon pixmaps and/or windows should place a property called WM_ICON_SIZE on the root. The contents of this property are listed in the following table.
Field Type Comments
max_width CARD32
max_height CARD32
width_inc CARD32
height_inc CARD32

For more details see section 14.1.12 in Xlib - C Language X Interface.

4.1.4. Changing Window State

From the client's point of view, the window manager will regard each of the client's top-level windows as being in one of three states, whose semantics are as follows:
クライアントの視点から見て、ウィンドウマネージャは中へ3州(その意味論は以下のとおりである)のうちの1州であるとして各々のクライアントのトップレベルのウィンドウを見るでしょう: In fact, the window manager may implement states with semantics other than those described above. For example, a window manager might implement a concept of an "inactive" state in which an infrequently used client's window would be represented as a string in a menu. But this state is invisible to the client, which would see itself merely as being in the Iconic state.
実際、ウィンドウマネージャは、上に記述されたもの以外に意味論を持った状態をインプリメントするかもしれません。例えば、ウィンドウマネージャは、希に使用されたクライアントのウィンドウがメニューの中でストリングとして表わされる、「不活発な」状態の概念をインプリメントするかもしれません。しかし、この状態は、クライアント(それは単に像の状態であることとし?ﾄそれ自体を見るだろう)に目に見えません。

Newly created top-level windows are in the Withdrawn state. Once the window has been provided with suitable properties, the client is free to change its state as follows:
新しく作成されたトップレベルのウィンドウは内向的な状態です。一旦ウィンドウが適切な特性を供給されたならば、クライアントは自由に以下のようにその状態を変更することができます:

Only the client can effect a transition into or out of the Withdrawn state. Once a client's window has left the Withdrawn state, the window will be mapped if it is in the Normal state and the window will be unmapped if it is in the Iconic state. Reparenting window managers must unmap the client's window when it is in the Iconic state, even if an ancestor window being unmapped renders the client's window unviewable. Conversely, if a reparenting window manager renders the client's window unviewable by unmapping an ancestor, the client's window is by definition in the Iconic state and must also be unmapped.
クライアントだけが、内向的な状態へ、あるいはその状態から推移を達成することができます。一旦クライアントがウィンドウならばそれが標準状態にあり、それが像の状態である場合、ウィンドウが地図に載っていなないだろう場合、もし左が内向的な状態を持っていれば、ウィンドウが写像されるでしょう。地図に載っていなない先祖ウィンドウがクライアントのウィンドウを見えなくしても、それが像の状態である場合、ウィンドウマネージャをReparentingすることはクライアントのウィンドウをunmapするに違いありません。反対に、reparentingするウィンドウマネージャが先祖を写像しないことにより見えないクライアントのウィンドウを与える場合、クライアントのウィンドウは像の状態の定義により、さらに地図に載っていなませんに違いあ?閧ﾜせん。

Advice to Implementors
実装者へのアドバイス

Clients can select for StructureNotify on their top-level windows to track transitions between Normal and Iconic states. Receipt of a MapNotify event will indicate a transition to the Normal state, and receipt of an UnmapNotify event will indicate a transition to the Iconic state.
正常で像の状態間の推移を追跡するために、クライアントはそれらのトップレベルのウィンドウ上のStructureNotifyのために選択することができます。MapNotifyのイベントの受取は、標準状態への推移を示すでしょう。また、UnmapNotifyのイベントの受取は、像の状態への推移を示すでしょう。

When changing the state of the window to Withdrawn, the client must (in addition to unmapping the window) send a synthetic UnmapNotify event by using a SendEvent request with the following arguments:
ウィンドウの状態を Withdrawn へ変更する場合、 取消しされて、 クライアントは (ウィンドウをアンマップことに加えて) 次のような引数を伴った SendEvent を使って、 synthetic UnmapNotify event を送らなければならない:
Argument Value
destination: The root
propagate: False
event-mask: ( SubstructureRedirect|SubstructureNotify )
event: an UnmapNotify with:
event: The root
window: The window itself
from-configure: False

Rationale
原理（理論的説明）

The reason for requiring the client to send a synthetic UnmapNotify event is to ensure that the window manager gets some notification of the client's desire to change state, even though the window may already be unmapped when the desire is expressed.
合成ののUnmapNotifyのイベントを送ることをクライアントに要求する理由はたとえ要望が表現される場合ウィンドウが既に地図に載っていなないかもしれなくても、ウィンドウマネージャがクライアントの要望のある通知に状態を変更させることを保証することです。

Advice to Implementors
実装者へのアドバイス

For compatibility with obsolete clients, window managers should trigger the transition to the Withdrawn state on the real UnmapNotify rather than waiting for the synthetic one. They should also trigger the transition if they receive a synthetic UnmapNotify on a window for which they have not yet received a real UnmapNotify .
旧式のクライアントとの互換性については、ウィンドウマネージャが、合成のものを待つことではなく実際のUnmapNotifyの上の内向的な状態への推移を引き起こすべきです。さらに、まだ実際のUnmapNotifyを受け取っていないウィンドウ上の合成のUnmapNotifyを受け取る場合、それらは推移を引き起こすべきです。

When a client withdraws a window, the window manager will then update or remove the WM_STATE property as described in section 4.1.3.1. Clients that want to re-use a client window (e.g. by mapping it again or reparenting it elsewhere) after withdrawing it must wait for the withdrawal to be complete before proceeding. The preferred method for doing this is for clients to wait for the window manager to update or remove the WM_STATE property.12
その後、クライアントがウィンドウを取消しする時、ウィンドウマネージャはセクション4.1.3.1に記述されるようなWM_STATE財産を更新するか削除するでしょう。 それを取消しした後にクライアント・ウィンドウ(例えばそれを再び写像するかそれを他のところにreparentingすることによる)を再度使用したいクライアントは、撤回が進行の前に完了していることを待つに違いありません。 これをする好ましい方法は、クライアントがウィンドウマネージャがWM_STATE財産を更新するか削除するのを待つことです。

If the transition is from the Normal to the Iconic state, the client should send a ClientMessage event to the root with:
推移がノーマルから像の状態まである場合、クライアントは次のものを備えた根にClientMessageのイベントを送り込むべきです:

Rationale
原理（理論的説明）

The format of this ClientMessage event does not match the format of ClientMessages in section 4.2.8. This is because they are sent by the window manager to clients, and this message is sent by clients to the window manager.
このClientMessageのイベントのフォーマットは、セクション4.2.8にClientMessagesのフォーマットと一致しません。これはそれらがクライアントにウィンドウマネージャによって送られるからです。また、このメッセージはウィンドウマネージャにクライアントによって送られます。

Other values of data[0] are reserved for future extensions to these conventions. The parameters of the SendEvent request should be those described for the synthetic UnmapNotify event.
データ[0]の他の値はこれらの協定に対する将来の拡張のために取っておかれます。SendEventリクエストのパラメーターは合成ののUnmapNotifyのイベントのために記述されたものであるべきです。

Advice to Implementors
実装者へのアドバイス

Clients can also select for VisibilityChange events on their top-level or icon windows. They will then receive a VisibilityNotify (state==FullyObscured) event when the window concerned becomes completely obscured even though mapped (and thus, perhaps a waste of time to update) and a VisibilityNotify (state!=FullyObscured) event when it becomes even partly viewable.
クライアントは、さらに、それらのトップレベルのウィンドウあるいはアイコンウィンドウに関するVisibilityChangeのイベントのために選択することができます。その後、関係のあるウィンドウが写像された(したがって恐らく最新版への時間の浪費)が完全に不明瞭になるようになる時、それらはVisibilityNotify(state==FullyObscured)出来事を受け取るでしょう、そしてそれが部分的に見えさえするようになる場合、VisibilityNotify(状態! =FullyObscured)出来事。

Advice to Implementors
実装者へのアドバイス

When a window makes a transition from the Normal state to either the Iconic or to the Withdrawn state, clients should be aware that the window manager may make transients for this window inaccessible. Clients should not rely on transient windows being available to the user when the transient owner window is not in the Normal state. When withdrawing a window, clients are advised to withdraw transients for the window.
ウィンドウが標準状態で推移を作る場合、に、一方の、その、像、あるいは、内向的な状態に、クライアントが、ウィンドウマネージャがこの得難いウィンドウ用に過渡現象を作るかもしれないことに気づいているべきです。クライアントは、一時的な所有者ウィンドウが標準状態にない場合にユーザに利用可能な一時的なウィンドウに依存してはなりません。ウィンドウを取消しする場合、クライアントはウィンドウ用過渡現象を取消しするように助言されます。

4.1.5. Configuring the Window

Clients can resize and reposition their top-level windows by using the ConfigureWindow request. The attributes of the window that can be altered with this request are as follows:
クライアントは ConfigureWindow リクエストを使用することにより トップレベルのウィンドウのサイズや位置を変えることができる。 このリクエストで変更することができるウィンドウの属性は次のとおり: The coordinate system in which the location is expressed is that of the root (irrespective of any reparenting that may have occurred). The border width to be used and win_gravity position hint to be used are those most recently requested by the client. Client configure requests are interpreted by the window manager in the same manner as the initial window geometry mapped from the Withdrawn state, as described in section 4.1.2.3. Clients must be aware that there is no guarantee that the window manager will allocate them the requested size or location and must be prepared to deal with any size and location. If the window manager decides to respond to a ConfigureRequest request by:
位置を表現する座標系はルートのものを使用する。 (発生したすべての reparent には関係なく) 使用される境界幅と win_gravity の位置に関するヒントは クライアントによって最も最近要求されたものである。 セクション 4.1.2.3 に記述されるように、 クライアントが構成するリクエストは初期のウィンドウ形状が Withdrawn 状態からマップしたのと同じ方法でウィンドウマネージャによって解釈される。 クライアントはウィンドウマネージャが サイズや位置に関する要求どおりに設定する、 あるいは任意のサイズ／位置に対処する準備していることが 保証されないことに留意しなければならない。 次の項目により ウィンドウマネージャが ConfigureRequest リクエストへの応答を決定した場合: The general rule is that coordinates in real ConfigureNotify events are in the parent's space; in synthetic events, they are in the root space.
一般的なルールは実際の ConfigureNotify event での座標は親の空間であるということである; synthetic event ではそれらはルートの空間にある。

Advice to Implementors
実装者へのアドバイス

Clients cannot distinguish between the case where a top-level window is resized and moved from the case where the window is resized but not moved, since a real ConfigureNotify event will be received in both cases. Clients that are concerned with keeping track of the absolute position of a top-level window should keep a piece of state indicating whether they are certain of its position. Upon receipt of a real ConfigureNotify event on the top-level window, the client should note that the position is unknown. Upon receipt of a synthetic ConfigureNotify event, the client should note the position as known, using the position in this event. If the client receives a KeyPress , KeyRelease , ButtonPress , ButtonRelease , MotionNotify , EnterNotify , or LeaveNotify event on the window (or on any descendant), the client can deduce the top-level window's position from the difference between the (event-x, event-y) and (root-x, root-y) coordinates in these events. Only when the position is unknown does the client need to use the TranslateCoordinates request to find the position of a top-level window.
実際の ConfigureNotify event でトップレベルのウィンドウがサイズ変更／移動されるケース、 およびウィンドウがサイズ変更されるが移動されないケースの 両方を受け取ることができるので、 クライアントは両者を識別することができない。 トップレベルのウィンドウの絶対的な位置を追跡しているクライアントは、 それらがその位置に確かに存在しているかどうか示す 状態情報を記録しておくべきである。 トップレベル・ウィンドウでの実際の ConfigureNotify event の受取に際して、 クライアントは位置が未知であることに注目するべきである。 synthetic ConfigureNotify event の受取に際して、クライアントは位置は既知であり、 このイベントの中の位置情報を使用していることに注意するべきである。 クライアントが ウィンドウ(あるいは任意の子孫上で)に関する KeyPress , KeyRelease , ButtonPress , ButtonRelease , MotionNotify , EnterNotify , LeaveNotify イベントを受け取る場合、 クライアントはこれらのイベントの (event-x, event-y) と (root-x, root-y) 座標の違いから トップレベルのウィンドウの位置を間に推定することができる。 クライアントはトップレベルのウィンドウの位置を見つけるために TranslateCoordinates リクエストを使う必要があるのは、 位置が未知の時のみである。

Clients should be aware that their borders may not be visible. Window managers are free to use reparenting techniques to decorate client's top-level windows with borders containing titles, controls, and other details to maintain a consistent look-and-feel. If they do, they are likely to override the client's attempts to set the border width and set it to zero. Clients, therefore, should not depend on the top-level window's border being visible or use it to display any critical information. Other window managers will allow the top-level windows border to be visible.
クライアントは境界が不可視になっていかもしれないことを考慮するべきである。 ウィンドウマネージャは、 一貫したルック・アンド・フィールを維持するため、 クライアントのトップレベルのウィンドウをタイトル、 コントロールおよび他の詳細を含んでいる境界で飾れるよう、 自由に reparent のテクニックを使用することができる。 それを行う場合、 クライアントの境界幅をセットする試みを無視して０をセットする。 したがってクライアントは トップレベルのウィンドウの境界が見えていることに依存してはならないし、 どんな重大な情報も表示するためにも使用してはならない。 トップレベルのウィンドウ境界が表示可能なウィンドウマネージャもある。

Convention
慣例

Clients should set the desired value of the border-width attribute on all ConfigureWindow requests to avoid a race condition.
クライアントは 競合条件を回避するすべての ConfigureWindow リクエストにおいて 希望する境界幅属性の値をセットするべきである。

Clients that change their position in the stack must be aware that they may have been reparented, which means that windows that used to be siblings no longer are. Using a nonsibling as the sibling parameter on a ConfigureWindow request will cause an error.
スタックの中の位置を変更するクライアントは、 reparent され、 ウィンドウのかつての兄弟関係が解消されているかもしれないことに 気づかなければならない。 ConfigureWindowリクエストにおいて sibling parameter として兄弟でないものを使用することは エラーを引き起こす。

Convention
慣例

Clients that use a ConfigureWindow request to request a change in their position in the stack should do so using None in the sibling field.
スタック中の位置を変更するために ConfigureWindow リクエストを使用するクライアントは sibling field に None を使用する。

Clients that must position themselves in the stack relative to some window that was originally a sibling must do the ConfigureWindow request (in case they are running under a nonreparenting window manager), be prepared to deal with a resulting error, and then follow with a synthetic ConfigureRequest event by invoking a SendEvent request with the following arguments:
もとは兄弟関係にあったウィンドウとのスタック中の関係により、 位置を決めなければならないクライアントは (例えば reparent しないウィンドウマネージャの下で実行されている場合) ConfigureWindow リクエストを実行しなければならず、 そのために生じるエラーにも対処する準備ができていなければならない。 そしてその時 次のような引数が伴った SendEvent の起動により synthetic ConfigureRequest event が続く:
Argument Value
destination: The root
propagate: False
event-mask: ( SubstructureRedirect|SubstructureNotify )
event: a ConfigureRequest with:
event: The root
window: The window itself
... Other parameters from the ConfigureWindow request

Window managers are in any case free to position windows in the stack as they see fit, and so clients should not rely on receiving the stacking order they have requested. Clients should ignore the above-sibling field of both real and synthetic ConfigureNotify events received on their top-level windows because this field may not contain useful information.
見栄えがするようウィンドウマネージャは どんな場合でもスタック中のウィンドウの位置を自由に決めることができる。 したがってクライアントは要求したリクエストを受け取ることに依存してはならない。 有意な情報を含んでいないので、 クライアントは トップレベル・ウィンドウから受けとった real and synthetic ConfigureNotify events 両方の above-sibling フィールドを無視するべきである。

4.1.6. Changing Window Attributes

The attributes that may be supplied when a window is created may be changed by using the ChangeWindowAttributes request. The window attributes are listed in the following table.
Attribute Private to Client
Background pixmap Yes
Background pixel Yes
Border pixmap Yes
Border pixel Yes
Bit gravity Yes
Backing-store hint Yes
Save-under hint No
Event mask No
Do-not-propagate mask Yes
Override-redirect flag No
Colormap Yes
Cursor Yes

Most attributes are private to the client and will never be interfered with by the window manager. For the attributes that are not private to the client:

4.1.7. Input Focus

There are four models of input handling:
The four input models and the corresponding values of the input field and the presence or absence of the WM_TAKE_FOCUS atom in the WM_PROTOCOLS property are listed in the following table:
Input Model Input Field WM_TAKE_FOCUS
No Input False Absent
Passive True Absent
Locally Active True Present
Globally Active False Present

Passive and Locally Active clients set the input field of WM_HINTS to True , which indicates that they require window manager assistance in acquiring the input focus. No Input and Globally Active clients set the input field to False , which requests that the window manager not set the input focus to their top-level window.

Clients that use a SetInputFocus request must set the time field to the timestamp of the event that caused them to make the attempt. This cannot be a FocusIn event because they do not have timestamps. Clients may also acquire the focus without a corresponding EnterNotify . Note that clients must not use CurrentTime in the time field.

Clients using the Globally Active model can only use a SetInputFocus request to acquire the input focus when they do not already have it on receipt of one of the following events:

In general, clients should avoid using passive-grabbed key events for this purpose, except when they are unavoidable (as, for example, a selection tool that establishes a passive grab on the keys that cut, copy, or paste).

The method by which the user commands the window manager to set the focus to a window is up to the window manager. For example, clients cannot determine whether they will see the click that transfers the focus.

Windows with the atom WM_TAKE_FOCUS in their WM_PROTOCOLS property may receive a ClientMessage event from the window manager (as described in section 4.2.8) with WM_TAKE_FOCUS in its data[0] field and a valid timestamp (i.e. not CurrentTime ) in its data[1] field. If they want the focus, they should respond with a SetInputFocus request with its window field set to the window of theirs that last had the input focus or to their default input window, and the time field set to the timestamp in the message. For further information, see section 4.2.7.

A client could receive WM_TAKE_FOCUS when opening from an icon or when the user has clicked outside the top-level window in an area that indicates to the window manager that it should assign the focus (for example, clicking in the headline bar can be used to assign the focus).

The goal is to support window managers that want to assign the input focus to a top-level window in such a way that the top-level window either can assign it to one of its subwindows or can decline the offer of the focus. For example, a clock or a text editor with no currently open frames might not want to take focus even though the window manager generally believes that clients should take the input focus after being deiconified or raised.

Clients that set the input focus need to decide a value for the revert-to field of the SetInputFocus request. This determines the behavior of the input focus if the window the focus has been set to becomes not viewable. The value can be any of the following:

Note that neither PointerRoot nor None is really safe to use.

Convention

Clients that invoke a SetInputFocus request should set the revert-to argument to Parent .

A convention is also required for clients that want to give up the input focus. There is no safe value set for them to set the input focus to; therefore, they should ignore input material.

Convention

Clients should not give up the input focus of their own volition. They should ignore input that they receive instead.

4.1.8. Colormaps

The window manager is responsible for installing and uninstalling colormaps on behalf of clients with top-level windows that the window manager manages.

Clients provide the window manager with hints as to which colormaps to install and uninstall. Clients must not install or uninstall colormaps themselves (except under the circumstances noted below). When a client's top-level window gets the colormap focus (as a result of whatever colormap focus policy is implemented by the window manager), the window manager will ensure that one or more of the client's colormaps are installed.

Clients whose top-level windows and subwindows all use the same colormap should set its ID in the colormap field of the top-level window's attributes. They should not set a WM_COLORMAP_WINDOWS property on the top-level window. If they want to change the colormap, they should change the top-level window's colormap attribute. The window manager will track changes to the window's colormap attribute and install colormaps as appropriate.

Clients that create windows can use the value CopyFromParent to inherit their parent's colormap. Window managers will ensure that the root window's colormap field contains a colormap that is suitable for clients to inherit. In particular, the colormap will provide distinguishable colors for BlackPixel and WhitePixel .

Top-level windows that have subwindows or override-redirect pop-up windows whose colormap requirements differ from the top-level window should have a WM_COLORMAP_WINDOWS property. This property contains a list of IDs for windows whose colormaps the window manager should attempt to have installed when, in the course of its individual colormap focus policy, it assigns the colormap focus to the top-level window (see section 4.1.2.8). The list is ordered by the importance to the client of having the colormaps installed. The window manager will track changes to this property and will track changes to the colormap attribute of the windows in the property.

If the relative importance of colormaps changes, the client should update the WM_COLORMAP_WINDOWS property to reflect the new ordering. If the top-level window does not appear in the list, the window manager will assume it to be of higher priority than any window in the list.

WM_TRANSIENT_FOR windows either can have their own WM_COLORMAP_WINDOWS property or can appear in the property of the window they are transient for, as appropriate.

Rationale

An alternative design was considered for how clients should hint to the window manager about their colormap requirements. This alternative design specified a list of colormaps instead of a list of windows. The current design, a list of windows, was chosen for two reasons. First, it allows window managers to find the visuals of the colormaps, thus permitting visual-dependent colormap installation policies. Second, it allows window managers to select for VisibilityChange events on the windows concerned and to ensure that colormaps are only installed if the windows that need them are visible. The alternative design allows for neither of these policies.

Advice to Implementors

Clients should be aware of the min-installed-maps and max-installed-maps fields of the connection setup information, and the effect that the minimum value has on the "required list" defined by the Protocol in the description of the InstallColormap request. Briefly, the min-installed-maps most recently installed maps are guaranteed to be installed. This value is often one; clients needing multiple colormaps should beware.

Whenever possible, clients should use the mechanisms described above and let the window manager handle colormap installation. However, clients are permitted to perform colormap installation on their own while they have the pointer grabbed. A client performing colormap installation must notify the window manager prior to the first installation. When the client has finished its colormap installation, it must also notify the window manager. The client notifies the window manager by issuing a SendEvent request with the following arguments:
Argument Value
destination: the root window of the screen on which the colormap is being installed
propagate: False
event-mask: ColormapChange
event: a ClientMessage with:
window: the root window, as above
type: WM_COLORMAP_NOTIFY
format: 32
data[0]: the timestamp of the event that caused the client to start or stop installing colormaps
data[1]: 1 if the client is starting colormap installation, 0 if the client is finished with colormap installation
data[2]: reserved, must be zero
data[3]: reserved, must be zero
data[4]: reserved, must be zero

This feature was introduced in version 2.0 of this document, and there will be a significant period of time before all window managers can be expected to implement this feature. Before using this feature, clients must check the compliance level of the window manager (using the mechanism described in section 4.3) to verify that it supports this feature. This is necessary to prevent colormap installation conflicts between clients and older window managers.

Window managers should refrain from installing colormaps while a client has requested control of colormap installation. The window manager should continue to track the set of installed colormaps so that it can reinstate its colormap focus policy when the client has finished colormap installation.

This technique has race conditions that may result in the colormaps continuing to be installed even after a client has issued its notification message. For example, the window manager may have issued some InstallColormap requests that are not executed until after the client's SendEvent and InstallColormap requests, thus uninstalling the client's colormaps. If this occurs while the client still has the pointer grabbed and before the client has issued the "finished" message, the client may reinstall the desired colormaps.

Advice to Implementors

Clients are expected to use this mechanism for things such as popup windows and for animations that use override-redirect windows. If a client fails to issue the "finished" message, the window manager may be left in a state where its colormap installation policy is suspended. Window manager implementors may want to implement a feature that resets colormap installation policy in response to a command from the user.

4.1.9. Icons

A client can hint to the window manager about the desired appearance of its icon by setting:
In the Iconic state, the window manager usually will ensure that:
Clients should observe the following conventions about their icon windows:

    Conventions


  1. The icon window should be an InputOutput child of the root.
  2. The icon window should be one of the sizes specified in the WM_ICON_SIZE property on the root.
  3. The icon window should use the root visual and default colormap for the screen in question.
  4. Clients should not map their icon windows.
  5. Clients should not unmap their icon windows.
  6. Clients should not configure their icon windows.
  7. Clients should not set override-redirect on their icon windows or select for ResizeRedirect events on them.
  8. Clients must not depend on being able to receive input events by means of their icon windows.
  9. Clients must not manipulate the borders of their icon windows.
  10. Clients must select for Exposure events on their icon window and repaint it when requested.

Window managers will differ as to whether they support input events to client's icon windows; most will allow the client to receive some subset of the keys and buttons.

Window managers will ignore any WM_NAME, WM_ICON_NAME, WM_NORMAL_HINTS, WM_HINTS, WM_CLASS, WM_TRANSIENT_FOR, WM_PROTOCOLS, WM_COLORMAP_WINDOWS, WM_COMMAND, or WM_CLIENT_MACHINE properties they find on icon windows.

4.1.10. Pop-up Windows

Clients that wish to pop up a window can do one of three things:
    They can create and map another normal top-level window, which will get decorated and managed as normal by the window manager. See the discussion of window groups that follows.
  1. If the window will be visible for a relatively short time and deserves a somewhat lighter treatment, they can set the WM_TRANSIENT_FOR property. They can expect less decoration but can set all the normal window manager properties on the window. An example would be a dialog box.
  2. If the window will be visible for a very short time and should not be decorated at all, the client can set override-redirect on the window. In general, this should be done only if the pointer is grabbed while the window is mapped. The window manager will never interfere with these windows, which should be used with caution. An example of an appropriate use is a pop-up menu.

Advice to Implementors

The user will not be able to move, resize, restack, or transfer the input focus to override-redirect windows, since the window manager is not managing them. If it is necessary for a client to receive keystrokes on an override-redirect window, either the client must grab the keyboard, or the client must have another top-level window that is not override-redirect and that has selected the Locally Active or Globally Active focus model. The client may set the focus to the override-redirect window when the other window receives a WM_TAKE_FOCUS message or one of the events listed in section 4.1.7 in the description of the Globally Active focus model.

Window managers are free to decide if WM_TRANSIENT_FOR windows should be iconified when the window they are transient for is. Clients displaying WM_TRANSIENT_FOR windows that have (or request to have) the window they are transient for iconified do not need to request that the same operation be performed on the WM_TRANSIENT_FOR window; the window manager will change its state if that is the policy it wishes to enforce.

4.1.11. Window Groups

A set of top-level windows that should be treated from the user's point of view as related (even though they may belong to a number of clients) should be linked together using the window_group field of the WM_HINTS structure.

One of the windows (that is, the one the others point to) will be the group leader and will carry the group as opposed to the individual properties. Window managers may treat the group leader differently from other windows in the group. For example, group leaders may have the full set of decorations, and other group members may have a restricted set.

It is not necessary that the client ever map the group leader; it may be a window that exists solely as a placeholder.

It is up to the window manager to determine the policy for treating the windows in a group. At present, there is no way for a client to request a group, as opposed to an individual, operation.

4.2. Client Responses to Window Manager Actions

The window manager performs a number of operations on client resources, primarily on their top-level windows. Clients must not try to fight this but may elect to receive notification of the window manager's operations.

4.2.1. Reparenting

Clients must be aware that some window managers will reparent their top-level windows so that a window that was created as a child of the root will be displayed as a child of some window belonging to the window manager. The effects that this reparenting will have on the client are as follows:
Clients that want to be notified when they are reparented can select for StructureNotify events on their top-level window. They will receive a ReparentNotify event if and when reparenting takes place. When a client withdraws a top-level window, the window manager will reparent it back to the root window if the window had been reparented elsewhere.

If the window manager reparents a client's window, the reparented window will be placed in the save-set of the parent window. This means that the reparented window will not be destroyed if the window manager terminates and will be remapped if it was unmapped. Note that this applies to all client windows the window manager reparents, including transient windows and client icon windows.

4.2.2. Redirection of Operations

Clients must be aware that some window managers will arrange for some client requests to be intercepted and redirected. Redirected requests are not executed; they result instead in events being sent to the window manager, which may decide to do nothing, to alter the arguments, or to perform the request on behalf of the client.

The possibility that a request may be redirected means that a client cannot assume that any redirectable request is actually performed when the request is issued or is actually performed at all. The requests that may be redirected are MapWindow , ConfigureWindow , and CirculateWindow .

Advice to Implementors

The following is incorrect because the MapWindow request may be intercepted and the PolyLine output made to an unmapped window:


MapWindow A
PolyLine A GC   ...

The client must wait for an Expose event before drawing in the window.14

This next example incorrectly assumes that the ConfigureWindow request is actually executed with the arguments supplied:


ConfigureWindow width=N height=M

The client should select for StructureNotify on its window and monitor the window's size by tracking ConfigureNotify events.

Clients must be especially careful when attempting to set the focus to a window that they have just mapped. This sequence may result in an X protocol error:


MapWindow B
SetInputFocus B

If the MapWindow request has been intercepted, the window will still be unmapped, causing the SetInputFocus request to generate the error. The solution to this problem is for clients to select for VisibilityChange on the window and to delay the issuance of the SetInputFocus request until they have received a VisibilityNotify event indicating that the window is visible.

This technique does not guarantee correct operation. The user may have iconified the window by the time the SetInputFocus request reaches the server, still causing an error. Or, the window manager may decide to map the window into Iconic state, in which case the window will not be visible. This will delay the generation of the VisibilityNotify event indefinitely. Clients must be prepared to handle these cases.

A window with the override-redirect bit set is immune from redirection, but the bit should be set on top-level windows only in cases where other windows should be prevented from processing input while the override-redirect window is mapped (see section 4.1.10) and while responding to ResizeRequest events (see section 4.2.9).

Clients that have no non-Withdrawn top-level windows and that map an override-redirect top-level window are taking over total responsibility for the state of the system. It is their responsibility to:

In effect, clients of this kind are acting as temporary window managers. Doing so is strongly discouraged because these clients will be unaware of the user interface policies the window manager is trying to maintain and because their user interface behavior is likely to conflict with that of less demanding clients.

4.2.3. Window Move

If the window manager moves a top-level window without changing its size, the client will receive a synthetic ConfigureNotify event following the move that describes the new location in terms of the root coordinate space. Clients must not respond to being moved by attempting to move themselves to a better location.

Any real ConfigureNotify event on a top-level window implies that the window's position on the root may have changed, even though the event reports that the window's position in its parent is unchanged because the window may have been reparented. Note that the coordinates in the event will not, in this case, be directly useful.

The window manager will send these events by using a SendEvent request with the following arguments:
Argument Value
destination: The client's window
propagate: False
event-mask: StructureNotify

4.2.4. Window Resize

The client can elect to receive notification of being resized by selecting for StructureNotify events on its top-level windows. It will receive a ConfigureNotify event. The size information in the event will be correct, but the location will be in the parent window (which may not be the root).

The response of the client to being resized should be to accept the size it has been given and to do its best with it. Clients must not respond to being resized by attempting to resize themselves to a better size. If the size is impossible to work with, clients are free to request to change to the Iconic state.

4.2.5. Iconify and Deiconify

A top-level window that is not Withdrawn will be in the Normal state if it is mapped and in the Iconic state if it is unmapped. This will be true even if the window has been reparented; the window manager will unmap the window as well as its parent when switching to the Iconic state.

The client can elect to be notified of these state changes by selecting for StructureNotify events on the top-level window. It will receive a UnmapNotify event when it goes Iconic and a MapNotify event when it goes Normal.

4.2.6. Colormap Change

Clients that wish to be notified of their colormaps being installed or uninstalled should select for ColormapNotify events on their top-level windows and on any windows they have named in WM_COLORMAP_WINDOWS properties on their top-level windows. They will receive ColormapNotify events with the new field FALSE when the colormap for that window is installed or uninstalled.

4.2.7. Input Focus

Clients can request notification that they have the input focus by selecting for FocusChange events on their top-level windows; they will receive FocusIn and FocusOut events. Clients that need to set the input focus to one of their subwindows should not do so unless they have set WM_TAKE_FOCUS in their WM_PROTOCOLS property and have done one of the following:
Clients should not warp the pointer in an attempt to transfer the focus; they should set the focus and leave the pointer alone. For further information, see section 6.2.

Once a client satisfies these conditions, it may transfer the focus to another of its windows by using the SetInputFocus request, which is defined as follows:

SetInputFocus
focus : WINDOW or PointerRoot or None
revert-to : { Parent , PointerRoot , None }
time : TIMESTAMP or CurrentTime

    Conventions

  1. Clients that use a SetInputFocus request must set the time argument to the timestamp of the event that caused them to make the attempt. This cannot be a FocusIn event because they do not have timestamps. Clients may also acquire the focus without a corresponding EnterNotify event. Clients must not use CurrentTime for the time argument.
  2. Clients that use a SetInputFocus request to set the focus to one of their windows must set the revert-to field to Parent .

4.2.8. ClientMessage Events

There is no way for clients to prevent themselves being sent ClientMessage events.
クライアントがそれ自身で ClientMessage のイベントを送られること防ぐ方法はない。

Top-level windows with a WM_PROTOCOLS property may be sent ClientMessage events specific to the protocols named by the atoms in the property (see section 4.1.2.7). For all protocols, the ClientMessage events have the following:
WM_PROTOCOLS プロパティを備えたトップレベルのウィンドウは、 プロパティの中のアトムによって指定されたプロトコルに特有の ClientMessage イベントを送られる可能性がある。 (section 4.1.2.7参照) すべてのプロトコルにおいて ClientMessage イベントは次の情報を持っている:

The remaining fields of the event, including the window field, are determined by the protocol.
ウィンドウ・フィールドを含む残るイベント・フィールドは プロトコルによって決定される。

These events will be sent by using a SendEvent request with the following arguments:
これらのイベントは次の引数を備えた SendEvent リクエストを使用することにより送られる:
Argument Value
destination: The client's window
propagate: False
event-mask: () empty
event: As specified by the protocol

4.2.8.1. Window Deletion

Clients, usually those with multiple top-level windows, whose server connection must survive the deletion of some of their top-level windows, should include the atom WM_DELETE_WINDOW in the WM_PROTOCOLS property on each such window. They will receive a ClientMessage event as described above whose data[0] field is WM_DELETE_WINDOW.
(通常、多数のトップレベルのウィンドウを備えた) (そのサーバー接続はそれらのトップレベルのウィンドウのうちのいくつかの削除から残存するに違いない) クライアントは個々のそのようなウィンドウ上の WM_PROTOCOLS プロパティにアトム WM_DELETE_WINDOW を含んでいるべきである。 それらは、 ClientMessage イベントを受け取る。 イベントには前述のようにデータ[0]フィールドが WM_DELETE_WINDOW でセットされている。

Clients receiving a WM_DELETE_WINDOW message should behave as if the user selected "delete window" from a hypothetical menu. They should perform any confirmation dialog with the user and, if they decide to complete the deletion, should do the following:
WM_DELETE_WINDOWメッセージを受け取ったクライアントは あたかもユーザが仮定したメニューから「ウィンドウ削除」を選択したかのように 作用するべきである。 完全に削除することを決定する場合、 ユーザに対しダイアログよる確認を行ない、 下記の処理も実行するべきである:

If the user aborts the deletion during the confirmation dialog, the client should ignore the message.
ダイアログよる確認でユーザが削除を無効にした場合、 クライアントはメッセージを無視するべきである。

Clients are permitted to interact with the user and ask, for example, whether a file associated with the window to be deleted should be saved or the window deletion should be cancelled. Clients are not required to destroy the window itself; the resource may be reused, but all associated state (for example, backing store) should be released.
クライアントはユーザと対話し尋ねることを許される。 例えば、削除されるウィンドウと関連付けられたファイルは保存するか、 ウィンドウ削除そのものを取り消されるべきである。 クライアントはウィンドウ自体を破壊することを要求されない; リソースは再利用されるかもしれないが、 関連付けられた状態 (例えば backing store) はすべて解放されるべきである。

If the client aborts a destroy and the user then selects DELETE WINDOW again, the window manager should start the WM_DELETE_WINDOW protocol again. Window managers should not use DestroyWindow requests on a window that has WM_DELETE_WINDOW in its WM_PROTOCOLS property.
クライアントがウィンドウの破壊を異常終了させて、 次にユーザが再び DELETE WINDOW を選択する場合、 ウィンドウマネージャは WM_DELETE_WINDOW プロトコルを再び始めるべきである。 ウィンドウマネージャは WM_PROTOCOLS プロパティに WM_DELETE_WINDOW を持っているウィンドウ上で DestroyWindow リクエストを使用してはならない。

Clients that choose not to include WM_DELETE_WINDOW in the WM_PROTOCOLS property may be disconnected from the server if the user asks for one of the client's top-level windows to be deleted.
ユーザがクライアントのトップレベルのウィンドウのうちの１つに削除を求めた場合、 WM_PROTOCOLS プロパティに WM_DELETE_WINDOW を含まないクライアントは サーバーからの接続を解除されるかもしれない。

4.2.9. Redirecting Requests

Normal clients can use the redirection mechanism just as window managers do by selecting for SubstructureRedirect events on a parent window or ResizeRedirect events on a window itself. However, at most, one client per window can select for these events, and a convention is needed to avoid clashes.

Convention

Clients (including window managers) should select for SubstructureRedirect and ResizeRedirect events only on windows that they own.

In particular, clients that need to take some special action if they are resized can select for ResizeRedirect events on their top-level windows. They will receive a ResizeRequest event if the window manager resizes their window, and the resize will not actually take place. Clients are free to make what use they like of the information that the window manager wants to change their size, but they must configure the window to the width and height specified in the event in a timely fashion. To ensure that the resize will actually happen at this stage instead of being intercepted and executed by the window manager (and thus restarting the process), the client needs temporarily to set override-redirect on the window.

Convention

Clients receiving ResizeRequest events must respond by doing the following:

If a window manager detects that a client is not obeying this convention, it is free to take whatever measures it deems appropriate to deal with the client.

4.3. Communication with the Window Manager by Means of Selections

For each screen they manage, window managers will acquire ownership of a selection named WM_Sn, where n is the screen number, as described in section 1.2.6. Window managers should comply with the conventions for "Manager Selections" described in section 2.8. The intent is for clients to be able to request a variety of information or services by issuing conversion requests on this selection. Window managers should support conversion of the following target on their manager selection:

Atom Type Data Received
VERSION INTEGER Two integers, which are the major and minor release numbers (respectively) of the ICCCM with which the window manager complies. For this version of the ICCCM, the numbers are 2 and 0.15

4.4. Summary of Window Manager Property Types

The window manager properties are summarized in the following table (see also section 14.1 of Xlib - C Language X Interface).
Name Type Format See Section
WM_CLASS STRING 8 4.1.2.5
WM_CLIENT_MACHINE TEXT & 4.1.2.9
WM_COLORMAP_WINDOWS WINDOW 32 4.1.2.8
WM_HINTS WM_HINTS 32 4.1.2.4
WM_ICON_NAME TEXT 4.1.2.2
WM_ICON_SIZE WM_ICON_SIZE 32 4.1.3.2
WM_NAME TEXT 4.1.2.1
WM_NORMAL_HINTS WM_SIZE_HINTS 32 4.1.2.3
WM_PROTOCOLS ATOM 32 4.1.2.7
WM_STATE WM_STATE 32 4.1.3.1
WM_TRANSIENT_FOR WINDOW 32 4.1.2.6
<^>

Christophe Tronche, ch.tronche@computer.org