Inter-Client Communication Conventions Manual(日本語訳)

概念としては、アトムは、クライアントが互いに情報をやり取りする際に使える一意の(唯一無二の、uniqueな)名前である。この名前というのはバイトの羅列だと考えてよい。但し、特定の符号化方式を持たない文字列のようなバイトの羅列である。 この羅列の要素は ASCII 文字であるとは限らず、大文字小文字の統一も行われない。^[1]

プロトコルの設計者らは、このようなバイト列が回線上を行ったり来たりするのはあまりにも不経済であると考えた。これに加えて、回線を通る際にはイベントのサイズが一定であること(実際 32 バイトである)、及び一部のイベントの内部にアトムが含まれていることから、バイト列を固定長で表現することが必要になった。

固定長の表現を可能にするため、サーバにバイト列を登録するプロトコル・リクエスト(InternAtom)が用意された。このリクエストは登録したバイト列と結び付いた３２ビットの値(上位３ビットは 0)を返す。逆の操作を行う関数も存在する(GetAtomName)。

X11プロトコルでは、多くのアトムを既定のものとして定めている。

「既定のアトム」という実装の技巧は、あらゆるアプリケーションが起動段階で使うであろうアトムを何度も設定(intern)しなくても済むようにするためのものである。リクエスト InternAtom は、ハンドシェイクを必要とするけれども、その結果は仕様から(a priori)予測可能である。

言語インタフェイスは、アトム-名前の対応表を手元に保持し、用のある時以外はこの情報を取得しないようにするべきだろう。例えば、CLX インタフェイスは、既定のアトムと他のアトムを区別しない。即ち、同インタフェイスでは全てのアトムはシンボルと見做される(訳註：要確認)。しかしながら、CLXの実装では大抵、シンボルもしくはアトムのキャッシュを保持し、且つ、このキャッシュを既定のアトムで初期化する。

組み込みアトムは、ASCIIの大文字を連ねた単語と、それを区切るアンダースコア(_)から成る。例えば「WM_ICON_NAME」のようなものである。X11 プロトコルの仕様書においては、各開発組織が独自の理由で使用するアトムの名前は、アンダースコアから始めるよう推奨している。組織間で名前が被らないように、適当な接頭辞を追加するものとする(例えば「_DEC_WM_DECORATION_GEOMETRY」)。

組み込みアトムの名前を上記の形式で定めたおかげで、LISP でもこのアトム名を自然な方法で扱えるようになった。「keyword constructors」を使えば、プログラマは組み込みアトムを LISP のアトムとして扱うことができる。もし組み込みアトムが全て大文字でなかったとしたら、特別なクォートの規約(special quoting conventions)を用いる必要があったであろう。

アトムの意味は、構造体 FONTPROP で使用する例を除き、X Window System コア・プロトコルの中に定めがない。FONTPROP における意味(使い方)について詳しく知りたければ、X Logical Font Description Conventions を見よ。

X プロトコルでは独立した空間を６つ定義しており、アトムの解釈はこの中で行われる。どのアトムも、６つの名前空間のそれぞれに応じて、有効な解釈を持ったり持たなかったりする。

あるプロトコルにおいて、一意の名前を持つ、同じ種類のオブジェクトが不特定数必要になることがある(この必要が生じるのは通常、オブジェクトが動的に生成され、前もって名前を決めておくことができないからである)。例えば、カラーマップを生成するプログラムでは、各スクリーン(screen)にカラーマップを提示するにあたって、セレクション機構を使うことがあり得る。その場合、同プログラムは各スクリーンに対して一つづつセレクション名を用意する必要がある。このような名前は辨別名(discriminated names)と呼ばれ、プログラム的な実体(entity)を利用して名前の差別化を図る。ここでいうプログラム的な実体(entity)には、次のようなものがある。

    スクリーン(screen)
    X リソース (ウィンドウ、カラーマップ、ビジュアルなど)
    クライアント

もし差別化に使う実体(entity)のそれぞれに対してその値に応じた名前を生成し、これによって一定不変の名前集合を一つ作ればよいというのであれば、辨別名は、通常の名前の後ろへ実体(entity)の値に応じた接尾辞を付けたものとなる。

辨別名の内容説明部分を name、頭に０の来ない１０進数を d、８桁の１６進数を x とし、大文字だけを使用した場合、辨別名は次のような形になる。

クライアントによって名前を差別化する場合は、そのクライアントが作成した X リソースの ID を用いる。このリソースはどんな型(type)でも良い。

単に被りのない名前の集合を生成すれば良いということもある(例えば、MULTIPLE セレクションの作業ウィンドウに属するプロパティ群の名前の集合)。このような名前は、集合が一つしかない場合、

Ud     (例、 U0  U1  U2  U3  ...)

のような形をとる。集合が複数ある場合(ここでは「FOO」と「BAR」という二つの集合があるとしよう)、

name_Ud     (例、FOO_U0  BAR_U0  FOO_U1  BAR_U1  ...)

のような形になる。Ud 単独の形を使用するのは、次の二つの場合に限るものとする。即ち、この名前を使用しているモジュールによって、関連する名前空間が完全に統制されていると分かっている場合、あるいは、同モジュールがこの名前を使う可能性のある実体(entities)全てと共同作業を行っている場合である。(特定のセレクションの為に作られたウィンドウに属するプロパティに名前を付ける時は、この作法で名前を定めてよい。名前を付けたいプロパティがルート・ウィンドウに属する時は、勿論そうではない。)

特に複雑な場合には、両方の差別化手法を組み合わせる必要が生じ得る。その時は、U 形式の部分を他方の形式の部分の後ろに持ってくることにする。

    FOO_R12345678_U23

クライアントは、セレクションの所有権を自発的に手放したい場合、同セレクションのアトムに対して SetSelectionOwner リクエストを実行する。その際、owner には None を指定し、time には同セレクション取得時に用いたタイムスタンプを指定する。

他にも方法はあり、クライアントは SetSelectionOwner リクエストの owner の値として使ったウィンドウを破壊してもよいし、クライアント自身が終了してもよい。どちらの場合も、消えたウィンドウやクライアントに属していたセレクションの所有権は None に戻ることになる。

あるクライアントがセレクションの所有権を抛棄した時、あるいは別のクラアントが先のクライアントの所有するセレクションに対して SetSelectionOwner を実行し、強制的にセレクションが移った時、それまでの所有者は SelectionClear イベントを受け取ることになる。イベント SelectionClear の定義は、セレクション所有者の仕事を見よ。

SelectionClear の timestamp は、セレクションの所有権が移った時刻である。同イベントの owner は、現在の所有者(訳註：前所有者)が SetSelectionOwner リクエストの際に指定したウィンドウである。

セレクションは任意の数だけ存在することができ、１つのセレクションには１つのアトムが名前として割り当てられる。しかし、クライアント間の規約(inter-client conventions)に合わせるには、クライアントは以下の３つのセレクションに対応するだけで良い。

他のセレクションも、仲の良いクライアント集団同士の私的な通信では自由に使用してよい。

要求者が ConvertSelection リクエストの引数 target に渡すアトムによって、返ってくるデータの型式(form)が決まる。この種のアトムの集合は拡張可能である。しかし、広く受け入れられ、基礎となってくれるような(ターゲット・アトムの)集合も必要である。この出発点として、現在までに提案されているものを下表に挙げる。

文献:

上の表は、時が経つに連れて大きくなると思われる。

セレクションの所有者は、下に挙げるターゲットには必ず対応していなければならない。これ以外のターゲットへの対応機能は、あってもなくても良い。

副作用のあるターゲットも存在する(例えば DELETE)。この種のターゲットの処理から曖昧さを除くには、MULTIPLE のプロパティに入っているアトムの対は同プロパティ内での並び順の通りに処理されなければならない。

一般に、副作用のあるターゲットへの変換では情報を返さない。言いかえると、NULL 型で長さ 0 のプロパティを返す(NULL 型とは、InternAtom に文字列「NULL」を渡して得られる値のことであり、数値 0 のことではない)。副作用を伴うリクエストでは常に、副作用の処理が終わってから同リクエストの変換が完結するようにしなければならない。リクエストの副作用が実行できない場合、その変換リクエストは拒否しなければならない。

こうした副作用のあるターゲットは、「PRIMARY セレクションと SECONDARY セレクションを交換する」といった操作を実装するのに使用する。

一般に、テキスト文字列(a text string)のプロパティで使われている文字の符号化方式は、そのプロパティの型(type)で表される。X コンソーシアムの採用した「フォントの命名基準」に則ったフォント名の中に現れる文字集合名と、文字列プロパティの型との間に、単純で可逆性のある対応関係があることが強く望まれる。

アトム TEXT は多型(polymorphic)のターゲットである。TEXT への変換を要求すると、所有者は、自分にとって都合の良い符号化方式のどれにでも変換することができる。どの符号化方式が選ばれたのかは、返されたプロパティの型で判断することになる。TEXT は、型として定義されてないので、セレクション変換リクエストが返すデータの型には成り得ない。

要求者は、所有者から特定の符号化方式でセレクションの中身を返してもらいたい場合、その符号化方式の名前をターゲットに指定して変換リクエストを出すものとする。

ターゲット・アトムの表の(型の欄の) TEXT という語は、登録されている符号化方式名の中の何れか１つを表す。実際の型は TEXT ではなく、STRING か、あるいは所有者が採用した符号化方式を表す ATOM である。

型・ターゲットとしての STRING は、ISO Latin-1 文字集合に制御文字の TAB (８進表記で 11)と NEWLINE (８進表記で 12)を加えたものを表す。TAB の幅の解釈は文脈(context)に依存する。現時点では、他の ASCII 制御文字は間違いなく STRING には含まれない。

型・ターゲットとしての COMPOUND_TEXT は、コンパウンド・テキスト相互変換形式を表す(訳註：要確認)。「Compound Text Encoding」を見よ。

テキスト・オブジェクトの中には、作り手も受け手の利用者も特定の文字集合を想定しておらず、0 を終端とするバイト列でありさえすれば足り、それ以外の縛りはない、という性質のものもある。セレクション機構の如何なる部分も、特定のバイト値が禁止されていると想定したり、２つの異なるバイト列が同じものとして扱われると想定したりはしない^[5]。こうしたオブジェクトに対しては C_STRING 型を使用する。

STRING、COMPOUND_TEXT、C_STRING 型のプロパティは、null 文字で区切られた要素のリストから成る。これ以外の符号化方式を用いる場合、適切なリストの形式を指定する必要がある。

セレクションの要求者は、セレクション・データを返す類のターゲットを指定した場合、返答として INCR 型^[6]のプロパティを受け取ることがある。

これは、セレクションの所有者が実際のデータを複数回に分けて順次送信するつもりであることを表す。INCR プロパティの中身は整数１個であり、セレクションのデータのバイト数の下界の数値が入る。セレクションの要求者と所有者は、セレクションのデータを次のように転送する。

セレクションの要求者が、要求したセレクションの代わりに返ってきた「type==INCR」のプロパティを削除することによって、転送処理が始まる。

セレクションの所有者は続いて、

セレクションの要求者は、

分割されたデータを転送するプロパティの中、最初のものの型が変換済みセレクションの型になる。残りの部分を転送するプロパティも同じ型でなければならない。

要求者が受け取るプロパティには、PIXMAP 型、BITMAP 型、DRAWABLE 型、WINDOW 型のものもある。どの型のプロパティにも、その型に応じた リソース ID が格納されている。これらのドローアブルに関する情報はリクエスト GetGeometry を用いてサーバから取得可能だが、以下のものはそうではない。

一般に要求者は、ターゲット・アトムの表で戻り値の型がドローアブルの一種であると記載されているターゲットを変換対象に指定する場合、(MULTIPLE の仕組みを使って)以下のターゲットへの変換も考えておくべきである。

SPAN 型のプロパティには、基数(cardinal)の対のリスト(訳註：配列の仲間のリスト)が入る。このリストの長さは、基数の個数と形式(訳註：format、８、１６、３２？)で決まる。基数の対の中、最初の数値は開始位置を表し、２番目のものは終了位置に 1 を加えたものを表す。先頭は 0 である。開始位置と終了位置の値が同じである場合、範囲(span)の幅は 0 であり、開始位置・終了位置はともに数値の指す位置の直前にある。数値の単位は、LINE_NUMBER や CHARACTER_POSITION といったターゲット・アトムで示す。

クライアントの最上位ウィンドウとは、オーバライド・リダイレクト(override-redirect)の属性が False であるウィンドウのことである。また、最上位ウィンドウは、ルート・ウィンドウの子であるか、あるいはウィンドウ・マネージャによって親を変更される直前までルート・ウィンドウの子であったものでなければならない。クライアントがウィンドウの親をルート・ウィンドウでないものに変更すれば、そのウィンドウはもはや最上位ウィンドウではない。しかし、クライアントがそのウィンドウの親をルート・ウィンドウに戻せば、同ウィンドウは再び最上位ウィンドウになれる。

クライアントは通常、下記のような定形の式を用いて、１つ以上のルート・ウィンドウの子供として自身の最上位ウィンドウを作成する。

window = XCreateSimpleWindow(display, DefaultRootWindow(display), xsh.x, xsh.y,
     xsh.width, xsh.height, border_width, border, background);

しかしながら、数あるルート・ウィンドウの中の特定のもの(１つ)を使いたい場合、クライアントは次のような式を用いる。

window = XCreateSimpleWindow(display, RootWindow(display, screen), xsh.x, xsh.y,
     xsh.width, xsh.height, border_width, border, background);

ルート・ウィンドウの指定を上書きできて、クライアント(ウィンドウ・マネージャを含む)がルート・ウィンドウでないウィンドウを擬似ルート・ウィンドウとして扱えるのが理想である。これによって、例えばウィンドウ・マネージャの試験ができるようになったり、アプリケーション固有のウィンドウ・マネージャを用いて、仲間のクライアントが所有する下位ウィンドウ群を制御できるようになったりする。このような動作を正確に実現するには拡張が必要であり、その設計は研究中である。

クライアント側から見ると、ウィンドウ・マネージャはクライアントの最上位ウィンドウを下記のいづれかの状態にあると見做すものと考えられる。

新たに作成されたウィンドウは、最初は Withdrawn 状態である。状態の遷移が起きるのは、最上位ウィンドウがマップされたり(訳註：表示可能状態になること)アンマップされたりした時と、ウィンドウ・マネージャが特定のメッセージを受け取った時である。詳しくは WM_HINTS プロパティ及びウィンドウの状態の変更を見よ。

クライアントは、１つ以上の最上位ウィンドウを持つに至った時は、このウィンドウにプロパティを設置し、自身の望む振る舞いをウィンドウ・マネージャに知らせるものとする。クライアントが指定しなかったプロパティについては、ウィンドウ・マネージャは自身にとって都合の良い値が設定されたものと見做す。特定のプロパティ値を当てにしているクライアントは、明示的にその値を指定しなければならない。ウィンドウ・マネージャは、クライアントが書き込んだプロパティを変更しないことになっている。

ウィンドウ・マネージャは、ウィンドウの状態が Withdrawn から別のものへ移る時には、これらのプロパティの内容を調査することになる。また、ウィンドウ・マネージャは、ウィンドウの状態が Iconic や Normal である時にも、一部のプロパティに変更がないか監視している。クライアントがこうしたプロパティの中の１つを変更する場合、Replace モードを用いて同プロパティ全体を新しいデータで上書きしなければならない。ウィンドウ・マネージャはこのプロパティの古い値は記憶していない。Replace モードを指定した ChangeProperty リクエスト１回で同プロパティのフィールド全てに適切な値が設定されなければならない。こうすることで、次のような場合でも新しいウィンドウ・マネージャが同プロパティの完全な内容を取得できるようになる。例えば、既存のウィンドウ・マネージャが壊れた場合、ウィンドウ・マネージャが一旦終了して再開する場合、あるいはセッション・マネージャによってセッションを一旦終了して再開する必要がある場合。

これらのプロパティの中には、ウィンドウやピクスマップのようなリソースの ID が入っているものもある。クライアントは、少なくともこの種のプロパティが設置されているウィンドウが存在する間は、そうしたリソースが存在し続けるように計らうものとする。

これらのプロパティ(クライアント・プロパティ)のサイズが予想よりも長かった場合、クライアントはそのプロパティの余った部分を無視するものとする。これらのプロパティを拡張する権限は X コンソーシアムにあり、私的な拡張を施すことは禁じられている。クライアントとウィンドウ・マネージャの間で私的な交信を追加で行うには、クライアント・プロパティとは別のプロパティを用いるべきである。この規則の唯一の例外は WM_PROTOCOLS プロパティである。このプロパティは、長さが任意であり、私的なプロトコルを表すアトムを保持することができる(WM_PROTOCOLS プロパティを見よ)。

以降の節では、クライアントが設定する必要のあるプロパティを１つづつ順番に説明する。これらのプロパティは「ウィンドウ・マネージャ・プロパティの型のまとめ」にある表に纏めてある。

width = base_width + ( i x width_inc )

height = base_height + ( j x height_inc )

前の節で述べたプロパティは、クライアントが自身の最上位ウィンドウに保持しなければならないものである。この節では、ウィンドウ・マネージャがクライアントの最上位ウィンドウとルートとに設置するプロパティについて述べる。

クライアントの視点からは、ウィンドウ・マネージャはクライアントの最上位ウィンドウ(の１つ１つ)が下記の３つの状態のいづれかであると見做しているように見える。３つの状態の意味は次の通り。

実際には、ウィンドウ・マネージャは上記以外の意味を持つ状態を実装することができる。たとえば、ウィンドウ・マネージャは「inactive(不活発)」状態という概念を実装して、ほとんど使われないクライアントのウィンドウをメニュー内の文字列として表示することができる。しかし、この状態はクライアントには認識できず、クライアントは自身がアイコン状態にあるものと考える。

新たに作成された最上位ウィンドウは Withdrawn 状態にある。ウィンドウに適切なプロパティが与えられた後は、クライアントは下記のように自由にその状態を変更することができる。

Withdrawn 状態への遷移及び Withdrawn 状態からの遷移を引き起こすことができるのは、クライアントだけである。クライアントのウィンドウが Withdrawn 状態を脱した場合、同ウィンドウが Normal 状態であれば同ウィンドウはマップされ、Iconic 状態であればアンマップされる。親の変更を行うウィンドウ・マネージャは、クライアントのウィンドウが Iconic 状態にある時は同ウィンドウをアンマップしなればならない。たとえ、同クライアント・ウィンドウが、アンマップされている先祖のウィンドウによって不可視にされているとしても。反対に、親変更を行うウィンドウ・マネージャがクライアントのウィンドウを、その先祖をアンマップすることによって不可視の状態にする場合、同クライアント・ウィンドウは定義上当然に Iconic 状態となり、アンマップされなければならない。

ウィンドウの状態を Withdrawn へ変更する場合、クライアントは(同ウィンドウをアンマップするのに加えて)、下記の引数を与えた SendEvent リクエストを使って、代用の UnmapNotify イベントを送信しなければならない。

クライアントがウィンドウを引っ込める(Withdrawn状態にする)場合には、ウィンドウ・マネージャは「WM_STATE プロパティ」で述べたように WM_STATE プロパティを更新するか削除する。クライアント・ウィンドウを引っ込めた後にそのまま同ウィンドウを再利用したい(再度マップしたり、別の場所に親を変更したり、等)と考えるクライアントは、退出(Withdrawn状態への変更)が完了するのを待ってから同処理を進めなければならない。この場合の望ましい方法は、ウィンドウ・マネージャによる WM_STATE プロパティの更新または削除をクライアントが待つことである。^[8]

Normal 状態から Iconic 状態へ遷移する場合、クライアントは下記の値を設定した ClientMessage イベントをルートに送信するものとする。

data[0] の他の値は、この規約の将来の拡張のために予約されている。SendEvent リクエストの引数は、代用の UnmapNotify イベントのところで述べたものと同じである。

クライアントは、ConfigureWindow リクエストを用いて自身の最上位ウィンドウの大きさを変更したり、同ウィンドウの再配置をしたりすることができる。このリクエストで変更できるウィンドウの属性は以下のものである。

位置を表す座標系は、いかなる親変更が起きたとしても関係なく、ルートの座標系である。ボーダ幅と win_gravity の位置のヒントとは、時間的に最も近くにクライアントが要求したものを使用する。クライアントの構成リクエスト(configure requests)をウィンドウ・マネージャが解釈する方法は、ウィンドウが Withdrawn 状態から脱した時、初めてウィンドウ・ジオメトリをマップする方法と同じである。この方法については「WM_NORMAL_HINTS プロパティ」で述べた。クライアントは、要求したサイズや位置をウィンドウ・マネージャが必ず割り付けてくれるとは限らないことを承知していなければならず、どのようなサイズや位置にも対処できるよう備えていなければならない。ウィンドウ・マネージャは ConfigureRequest に対して次のように応答する。

原則として、本物の ConfigureNotify イベントに入っている座標は親を基準としたものであり、代用のイベントに入っている座標はルートを基準としたものである。

クライアントは、自身のボーダが表示されない可能性があることを承知しておくべきである。ウィンドウ・マネージャは、親変更の手法を用いてタイトルと操縦部品(controls)とその他の装飾(details)とを含む「ボーダ」でクライアントの最上位ウィンドウを自由に修飾し、一貫した look-and-feel を維持することができる。その場合、ウィンドウ・マネージャは、ボーダ幅を設定しようとするクライアントの試みを無視して、ボーダ幅を 0 にしてしまうことがある。したがって、クライアントは、最上位ウィンドウのボーダが表示されることを当てにしたり、最上位ウィンドウのボーダを用いて重要な情報を表示しようとしたりしないものとする。このような手法を用いないウィンドウ・マネージャは、最上位ウィンドウのボーダの表示を妨げない。

ウィンドウの前後の順序を変更するクライアントは、自身の親が変更されている可能性を考慮しなければならない。これは、かつて兄弟だったウィンドウが今では兄弟でない可能性を考慮しなければならないということである。ConfigureWindow リクエストの引数 sibling に兄弟でないウィンドウを渡すとエラーが起きる。

かつて兄弟だったウィンドウを基準として自身の前後の順序を変えなければならないクライアントは、次のことを行わなければならない。即ち、ConfigureWindow リクエストを使用し(親変更を行わないウィンドウ・マネージャの下でクライアントが動作している場合)、その結果として生じるエラーに備え、次いで下記の値を設定した SendEvent リクエストを実行して代用の ConfigureRequest イベントを送信しなければならない。

いづれにしても、ウィンドウ・マネージャは自分が合うと思うようにウィンドウ群の前後の順序を変更することができる。そのため、クライアントは、自身が要求したとおりの積み重ね順序を与えられることを当てにするべきでない。クライアントは、自身の最上位ウィンドウに関して受信した ConfigureNotify イベント(本物・代用の両方)の above-sibling フィールドを無視するべきである。このフィールドの情報が有用でない可能性があるからである。

ウィンドウ作成時に与えられる属性(attributes)は、ChangeWindowAttributes リクエストを使って変更することができる。ウィンドウの属性を下表に挙げる。

大半の属性はクライアント専用であり、ウィンドウ・マネージャに干渉されることはない。クライアント専用でない属性については以下の通り。

入力処理には４つの型式がある。

以上の４つの入力モデルと、それに対応する input フィールド(訳注：WM_HINTSの input フィールド)の値と WM_PROTOCOLS プロパティにおける WM_TAKE_FOCUS アトムの有無とを次の表にまとめる。

Passive 型式と Locally Active 型式のクライアントは、WM_HINTS の input フィールドに True を設定して、入力フォーカスの取得にウィンドウ・マネージャの助力が必要であることを表す。No Input 型式と Globally Active 型式のクライアントは、input フィールドに False を設定することによって、ウィンドウ・マネージャが自身の最上位ウィンドウに入力フォーカスを設定しないよう要求する。

SetInputFocus リクエストを使用するクライアントは、その切っ掛けとなったイベントのタイムスタンプを引数 time に設定しなければならない。FocusIn イベントは、タイムタンプを持たないので、切っ掛けのイベントにはなり得ない。クライアントは、対応する EnterNotify 無しにフォーカスを取得することがある。クライアントは、引数 time に CurrentTime を渡してはならない。

Globally Active 型式を使うクライアントは、下記のイベントのいづれかを受け取った時に未だ入力フォーカスを持っていない場合に限って、入力フォーカスを取得する SetInputFocus リクエストを使用することができる。

原則として、クライアントは、受動的に占有したキー・イベントをこの目的に使用するのを避けるべきである。但し、これが避けられない場合(たとえば、カット、コピー、ペーストを行うキーに対して受動的な占有を確立するセレクション・ツールなど)は例外である。

あるウィンドウにフォーカスを設定するよう利用者がウィンドウ・マネージャへ命令する方法は、ウィンドウ・マネージャが決定する。たとえば、クライアントは、フォーカスを移すためのクリックをウィンドウ・マネージャが評価するか否かを決めることはできない。

WM_PROTOCOLS プロパティに WM_TAKE_FOCUS アトムがあるウィンドウは、ウィンドウ・マネージャから次のような ClientMessage イベントを受け取ることがある(ClientMessage イベントで述べるように)。即ち、data[0] フィールドにはアトム WM_TAKE_FOCUS が入っており、data[1] フィールドには有効なタイムスタンプ(すなわち CurrentTime でないタイムスタンプ)が入っている ClientMessage イベントを受け取ることがある。(クライアントは、)そのようなウィンドウへフォーカスを与えたい場合、次のように引数を指定した SetInputFocus リクエストで答える。即ち、引数 window には、クライアントのウィンドウの中で最後に入力フォーカスを持っていたもの、あるいはデフォルトの入力ウィンドウを指定し、引数 time には上記 ClientMessage に入っているタイムスタンプを指定した SetInputFocus リクエストで答える。「入力フォーカス」も参照。

アイコンから元に戻った場合(ウィンドウを開いた場合)、あるいは利用者が最上位ウィンドウの外側の領域の中、ウィンドウ・マネージャにフォーカスを割り当てるよう指示する領域をクリックした場合(たとえば、ヘッドライン・バーのクリックを以ってフォーカスを割り当てる合図と為すことができる)、クライアントは WM_TAKE_FOCUS を受け取ることがある。

こうした規則の目的は、ウィンドウ・マネージャが最上位ウィンドウへ入力フォーカスを割り当てるにあたって、最上位ウィンドウ(を持つクライアント)が入力フォーカスを自身の下位ウィンドウへ割り当てられるようにすること、及び同ウィンドウ(を持つクライアント)が入力フォーカスの提供を拒否できるようにすることである。たとえば、ウィンドウ・マネージャが通常「クライアントがアイコン状態を脱した時やそのウィンドウが前面に出た時には入力フォーカスを取得するべきだ」と考えているとしても、現在フレームが開いていない時計やテキスト・エディタは入力フォーカスの取得を望まない可能性がある。

入力フォーカスを設定するクライアントは、SetInputFocus リクエストの引数 revert-to の値を決める必要がある。これによって、フォーカスを設定したウィンドウが可視状態でなくなった時の入力フォーカスの動きが決まる。引数 revert-to が取り得る値は次のいづれかである。

PointerRoot も None も、使用するのは安全でない。

入力フォーカスを抛棄したいクライアントのための規約も必要である。そのようなクライアントにとっては、入力フォーカスの設定先として安全な値が存在しない。したがって、そうしたクライアントは入力データを無視するものとする。

ウィンドウ・マネージャに管理される最上位ウィンドウを持つクライアントのためにカラーマップの組み込み(installing)と解放(uninstalling)を行うのは、ウィンドウ・マネージャの仕事である。

クライアントは、どのカラーマップを組み込んだり解放したりするのかについて、ヒントをウィンドウ・マネージャに提供する。クライアントはカラーマップを自分で組み込んだり解放したりしてはいけない(後ほど述べるような状況にある場合は除く)。クライアントの最上位ウィンドウがカラーマップ・フォーカスを得た場合(ウィンドウ・マネージャがどのようなカラーマップ・フォーカス指針を実装した結果なのかは問わない)、ウィンドウ・マネージャはクライアントのカラーマップの中の１個以上を必ず組み込む。

クライアントの最上位ウィンドウと下位ウィンドウが全て同じカラーマップを使う場合、同クライアントは最上位ウィンドウのウィンドウ属性の colormap フィールドにそのカラーマップの ID を設定するものとする。(訳註：この場合には、)クライアントは最上位ウィンドウに WM_COLORMAP_WINDOWS プロパティを設定してはいけない。クライアントは、カラーマップを変更したい場合、最上位ウィンドウのウィンドウ属性の colormap を変更する。ウィンドウ・マネージャはこの colormap 属性の変更を察知して適当なカラーマップを組み込む。

ウィンドウを作成するクライアントは、CopyFromParent という値を使って、親のカラーマップを引き継ぐことができる。ウィンドウ・マネージャは、ルート・ウィンドウの colormap フィールドにクライアントが継承するのに適したカラーマップが入っているよう取り計らう。特に、同カラーマップが BlackPixel と WhitePixel に区別可能な色を備えているようにする。

最上位ウィンドウとはカラーマップ要件を異にする下位ウィンドウと override-redirect・ポップアップ・ウィンドウとを持つ最上位ウィンドウには、WM_COLORMAP_WINDOWS プロパティを持たせるものとする。このプロパティには、次のようなカラーマップを持つウィンドウの ID のリストが入る。即ち、ウィンドウ・マネージャが自身のカラーマップ・フォーカス方針に則りカラーマップ・フォーカスを最上位ウィンドウに割り当てる時に組み込むべきとされるカラーマップである(WM_COLORMAP_WINDOWS プロパティ を見よ。)。このリストの中身は、クライアントから見てカラーマップを組み込む重要性が高いと思われる順に並んでいる。ウィンドウ・マネージャは、このプロパティの変更を監視し、同プロパティ中のウィンドウのカラーマップ属性の変更をも監視する。

クライアントは、カラーマップの重要性の順序に変更があった場合、新たな順序を反映するように WM_COLORMAP_WINDOWS プロパティを更新するものとする。最上位ウィンドウが同プロパティ中のリストに含まれていない場合、ウィンドウ・マネージャは、同ウィンドウの重要度がリスト中のどのウィンドウのものよりも高いと考える。

WM_TRANSIENT_FOR プロパティを持つウィンドウは、自分自身で WM_COLORMAP_WINDOWS プロパティを保持しても良いし、自分を一時的に活用しているウィンドウのプロパティ(WM_COLORMAP_WINDOWS)の中に(IDとして)納まるだけでも良い。

クライアントは、可能な時はいつでも、上述の仕組みを利用するものとし、ウィンドウ・マネージャが自由にカラーマップを組み込めるようにするものとする。けれどもクライアントは、ポインタの占有を保持している間は、自力でカラーマップの組み込みを行うことが許されている。カラーマップの組み込みを行うクライアントは、最初の組み込みに先立ってウィンドウ・マネージャに下記の通知を行わなければならない。クライアントは、カラーマップ組み込みを終えた時にもウィンドウ・マネージャへの通知を行わなければならない。クライアントは、以下の引数を与えて SendEvent リクエストを発行することによって、ウィンドウ・マネージャへの通知を行う。

この機能は、本規約のバージョン 2.0 から採用されたものである。そのため、全てのウィンドウ・マネージャがこの機能を実装するまで(そのように想定できるようになるまで)相当の時間がかかるであろう。クライアントは、この機能を使う前に、ウィンドウ・マネージャが則っている規約の版を調べ、ウィンドウ・マネージャがこの機能に対応しているか確認しなければならない(「セレクションを通じてウィンドウ・マネージャと交信」で述べる仕組みを利用する)。これは、クライアントと古いウィンドウ・マネージャとの間でカラーマップの組み込みが衝突するのを防ぐために必要なことである。

ウィンドウ・マネージャは、クライアントがカラーマップ組み込みの制御権を要求している間、カラーマップの組み込みを差し控えるものとする。ウィンドウ・マネージャは、クライアントがカラーマップの組み込みを終えた時に自身のカラーマップ・フォーカス方針を復活させられるように、組み込まれたカラーマップの集合(の変更)を監視し続けるものとする。

この手続きには競合条件がある。クライアントが通知を発した後もカラーマップを組み込み続けてしまう状況が発生し得る。たとえば、ウィンドウ・マネージャがいくつかの InstallColormap リクエストを発行してしまい、そのリクエスト群がクライアントの SendEvent と InstallColormap リクエスト群の後でなければ実行されない場合、クライアントのカラーマップの解放が行われてしまう。(訳註：InstallColormap には副作用があり、組み込むよう指定したカラーマップとは別のカラーマップが X サーバによって暗黙のうちに解放されてしまうことがある。) これが起こった時、クライアントが依然としてポインタを占有しており、且つクライアントが未だ「完了」の通知を発していない場合、同クライアントは目的のカラーマップを再度組み込もうとするかもしれない。

クライアントは、自身のアイコンの望ましい外観について、ウィンドウ・マネージャにヒントを与えることができる。次の方法による。

ウィンドウがアイコン状態にある時、ウィンドウ・マネージャは以下のことを保証する。

クライアントは、自身のアイコン・ウィンドウにつき、以下の規約を遵守すべきである。

ウィンドウ・マネージャには、(クライアントの)アイコン・ウィンドウへの入力イベントに対応している者とそうでない者がある。大半のウィンドウ・マネージャは、クライアントが一部のキーやボタンを受け取ることを妨げない。

ウィンドウ・マネージャは、アイコン・ウィンドウが持つ次のプロパティを無視する。即ち、WM_NAME、WM_ICON_NAME、WM_NORMAL_HINTS、WM_HINTS、WM_CLASS、WM_TRANSIENT_FOR、WM_PROTOCOLS、WM_COLORMAP_WINDOWS、WM_COMMAND、及び WM_CLIENT_MACHINE プロパティを無視する。

ウィンドウをポップアップしたいクライアントは、次の３つの方法を用いることができる。

ウィンドウ・マネージャは、 WM_TRANSIENT_FOR ウィンドウを一時的に活用しているウィンドウがアイコン状態になった場合に、当の WM_TRANSIENT_FOR ウィンドウをアイコン化するか否かを自由に決めることができる。WM_TRANSIENT_FOR ウィンドウを表示しているクライアントは、同ウィンドウを活用していたウィンドウがアイコン化された場合でも(もしくはアイコン化されるよう要求があった場合でも)、当の WM_TRANSIENT_FOR ウィンドウに対して同様の処理を実施するよう要請する必要は無い。このような WM_TRANSIENT_FOR ウィンドウの状態を変更することがウィンドウ・マネージャの方針であれば、同ウィンドウ・マネージャはそのように行動することになる。

利用者から見て、互いに関連があるものとして扱うべきだと思われる最上位ウィンドウの群れは(たとえそれらが別々のクライアントに所属しているとしても)、WM_HINTS 構造体の window_group フィールドを用いて一纏めにするものとする。

一纏まりのウィンドウの中の１つ(他のウィンドウが参照する者)は、グループ・リーダーとなり、個々のプロパティとは違う形でそのグループの情報を保持する。ウィンドウ・マネージャは、グループ・リーダーの扱いとグループ内の他のウィンドウの扱いとに差をつけてもよい。たとえば、グループ・リーダーには完全な装飾を施し、他のグループ・メンバーには一部の装飾しか施さないということも可能である。

グループ内のウィンドウの扱い方を決めるのは、ウィンドウ・マネージャの仕事である。今のところ、クライントがグループ単位の処理を要求する手段は存在しない(ウィンドウ単位の場合とは異なる)。

クライアントは次のことを承知していなければならない。即ち、クライアントの最上位ウィンドウの親を変更するウィンドウ・マネージャが存在し、その結果、ルートの子として作成されたウィンドウが、同ウィンドウ・マネージャに属する何らかのウィンドウの子として表示される可能性があることを承知していなければならない。この親変更は、クライアントに対して以下の影響を与える。

親が変更された時に通知を受け取りたいクライアントは、自身の最上位ウィンドウに関して StructureNotify イベントを選択することができる。同クライアントは、親変更が起きた場合、その時点で ReparentNotify イベントを受け取る。クライアントが最上位ウィンドウを引っ込めた(withdraw)場合、これまで同ウィンドウがルート・ウィンドウ以外の親を与えられていたのであれば、ウィンドウ・マネージャは同ウィンドウの親をルート・ウィンドウに戻すことになる。

ウィンドウ・マネージャがクライアントのウィンドウの親を変更した場合、親変更されたウィンドウは新たに親になったウィンドウ(訳註：を作成したクライアント･･･例えばウィンドウ・マネージャ)のセーブセット(save-set)に入る。これは次のことを意味する。即ち、親変更されたウィンドウは、ウィンドウ・マネージャが終了した場合でも破棄されないこと、また、アンマップされた状態であれば再マップされることを意味する。この処理は、ウィンドウ・マネージャが親変更を行うクライアント・ウィンドウ全てに適用されることに注意。一時的な(transient)ウィンドウ及びクライアントのアイコン・ウィンドウも、こうしたクライアント・ウィンドウに含まれる。

クライアントは、一部のウィンドウ・マネージャが一部のクライアント・リクエストを横取りしてリダイレクト(リクエストの配送先の変更)することを承知していなければならない。リダイレクトされたリクエストが実行されることはない。代わりにこのようなリクエストはイベントになってウィンドウ・マネージャへ送られる。同イベントを受け取ったウィンドウ・マネージャはクライアントに代わって、何もしなかったり引数を変更したりそのままのリクエストを実行したりする。

リクエストがリダイレクトされる可能性があるということは、クライアントは次のことを仮定できないこと意味する。即ち、リダイレクト可能なリクエストがリクエスト発行時に実際に実行されること、あるいは時点を問わずとにかく実際に実行されることを仮定できない。リダイレクトされる可能性があるリクエストは MapWindow、ConfigureWindow、及び CirculateWindow である。

override-redirect のビットが立てられているウィンドウはリダイレクトされない。このビットは、override-redirect ウィンドウがマップされている間(「ポップアップ・ウィンドウ」を見よ)や ResizeRequest イベントに応答している間(「リクエストをリダイレクトする」を見よ)に他のウィンドウが入力を処理しないようにする場合に限って、最上位ウィンドウに設定するものとする。

Withdrawn 状態でない最上位ウィンドウを１つも持たないクライアントであって、且つ override-redirect の最上位ウィンドウを１つ持つ者は、システムの状態に対する全責任を引き継ぐ。このようなクライアントは以下の仕事をしなければならない。

事実上、この種のクライアントは一時的なウィンドウ・マネージャとして振る舞う。このような手法を用いるのは止めるべきである。なぜかというと、このようなクライアントはウィンドウ・マネージャが維持しようとしているユーザ・インタフェイスの方針を知らない上、このようなクライアントのユーザ・インタフェイスの振る舞いは、多くを要求しないクライアントのユーザ・インタフェイスの振る舞いと衝突しがちだからである。

ウィンドウ・マネージャが最上位ウィンドウのサイズを変更することなく位置を変更した(移動させた)場合、クライアントはウィンドウの移動直後に代用の ConfigureNotify イベントを受け取る。同イベントには、ルートの座標空間における新しい位置が入っている。クライアントはこの移動に対して、より良い位置に自分を移動させようとする試みで応えてはならない。

最上位ウィンドウに関する本物の ConfigureNotify イベントは全て、同ウィンドウのルートの座標空間における位置が変わった可能性があることを示す。たとえ同イベントが「ウィンドウの位置がその親の座標空間において変更されてない」と報告しているとしても、ウィンドウの親が変更されている可能性があるので、同様に解釈する。この場合、イベントに入っている座標は直接役に立つものではない。

ウィンドウ・マネージャがこのイベントを送信するには、次の引数を与えた SendEvent リクエストを用いる。

クライアントは、自身の最上位ウィンドウに関して StructureNotify イベントを選択することで、サイズ変更の通知を受け取るよう設定することができる。クライアントが受け取るのは ConfigureNotify イベントである。同イベント内のサイズの情報は正しいものではあるが、位置情報は親ウィンドウ(ルートではない場合がある)の座標空間におけるものである。

サイズ変更に対してクライアントが取るべき反応は、与えられたサイズを受け入れ、そのサイズで最善を尽くすことである。クライアントはこのサイズ変更に対して、自分をより良いサイズに変更しようという試みで応えてはならない。そのサイズではうまく動けない場合、クライアントはアイコン状態への変更を要求することができる。

Withdrawn 状態でない最上位ウィンドウは、マップされている時は Normal 状態であり、アンマップされている時は Iconic 状態である。これは、同ウィンドウの親が変更されている場合でも当てはまる。ウィンドウ・マネージャは、このウィンドウがアイコン状態へ移行する時、その親とともにこのウィンドウをアンマップする。

クライアントは、最上位ウィンドウに関して StructureNotify イベントを選択することで、上記の状態変更の通知を受け取るよう設定することができる。この設定をしたクライアントは、アイコン状態になる時には UnmapNotify イベントを、通常状態になる時には MapNotify イベントを受け取る。

クライアントは、自身のカラーマップの組み込みや解放について通知を受けたいのであれば、自身の最上位ウィンドウ、及び最上位ウィンドウの WM_COLORMAP_WINDOWS プロパティで指定した全てのウィンドウに関して、ColormapNotify イベントを選択するものとする。クライアントは、こうしたウィンドウのカラーマップが組み込まれたり解放されたりした時に、new フィールドに FALSE の入った ColormapNotify イベントを受け取ることになる。

クライアントは、自身の最上位ウィンドウに関して FocusChange イベントを選択して、入力フォーカスを得た時に通知を受けられるよう要求することができる。こうしたクライアントは、FocusIn イベントと FocusOut イベントを受け取ることになる。クライアントは、自身の下位ウィンドウのいづれかに入力フォーカスを設定する必要がある場合、自身の WM_PROTOCOLS プロパティに WM_TAKE_FOCUS を設定した上で下記のいづれかを行っていない限り、下位ウィンドウに入力フォーカスを設定しないものとする。

クライアントは、フォーカスを移そうとしてポインタをワープさせたりしないものとする。ポインタには触れずにフォーカスだけを設定するべきである。「ポインタ」も参照。

クライアントは、一度上記の条件を満せば、SetInputFocus リクエストを用いて自分の有する別のウィンドウへフォーカスを移すことができる。このリクエストは次のように定義されている。

SetInputFocus

クライアントは、ClientMessage イベントが自分に送られてくるのを阻止することはできない。

WM_PROTOCOLS プロパティを持つ最上位ウィンドウには、同プロパティ内のアトムで指定したプロトコル固有の ClientMessage イベントが送られてくる(「WM_PROTOCOLS プロパティ」を見よ)。この ClientMessage イベントは、いづれのプロトコルのものであっても下記の内容を含んでいる。

window フィールドをはじめとした同イベントのその他のフィールドの内容は、プロトコル次第である。

このイベントは、下記の引数を与えた SendEvent リクエストを使って送信される。

通常のクライアントは、親ウィンドウに関して SubstructureRedirect イベントを選択するか、あるいは子ウィンドウに関して ResizeRedirect イベントを選択すると、ウィンドウ・マネージャと同じようにリダイレクトの機構を使用することができる。但し、これらのイベントを選択できるのは１つのウィンドウにつき１つのクライアントだけなので、衝突を避けるために規約が必要となる。

クライアントは、自身がサイズ変更された時に特別な動作を行う必要がある場合、自身の最上位ウィンドウに関して ResizeRedirect イベントを選択することができる。こうしたクライアントはウィンドウ・マネージャが同クライアントのウィンドウのサイズを変更した時に ResizeRequest イベントを受け取るけれども、実際にはサイズ変更は行われない。クライアントは、ウィンドウ・マネージャがクライアントのサイズを変更したがっているという情報を好きなように利用できるけれども、適切な時間内に上記イベントで指定された幅と高さにウィンドウを構成しなければならない。この段階で、ウィンドウ・マネージャがサイズ変更のリクエストを横取りして実行するのではなく(つまりサイズ変更の手続きを最初からやり直すのではなく)、実際にサイズ変更が行われるようにするには、クライアントはウィンドウに対して一時的に override-redirect 属性を設定する必要がある。

ウィンドウ・マネージャは、クライアントがこの規約に従っていないことを発見した場合、このクライアントへの対処として相応しいと思われる処置を何でも自由に実行することができる。