この文書は Extended Window Manager Hints (EWMH、拡張ウィンドウ・マネージャ・ヒント)の仕様書の最新版である。本文書の正規ページの所在は http://www.freedesktop.org であり、バグを報告したり次の版の開発に貢献したりする方法の説明もそこに書いてある。

この仕様書は、ウィンドウ・マネージャ、コンポジット・マネージャ、アプリケーション、ユーティリティなど、デスクトップ環境を構成する者らの間のやり取りについて定めている。この仕様書は Inter-Client Communication Conventions Manual [ICCCM(ICCCM日本語訳)] を補強するものであり、ICCCM はウィンドウ・マネージャのやり取りの中、もっと低水準のものについて定めている。現代のデスクトップ・ユーザが当然のものとして期待している機能の多くについて、ICCCM ではその実装方法を用意していない。もともと GNOME と KDE の両デスクトップ・プロジェクトでは、そうした機能に対応するために ICCCM に対する独自の拡張を開発していた。この仕様書は、いかなるデスクトップ環境でも採用できる類の ICCCM の拡張群を規格化し、この規格化された拡張群で先の慣習的拡張を置き換えるものである。

本文書においてキー・ワード「MUST」「MUST NOT」「REQUIRED」「SHALL」「SHALL NOT」「SHOULD」「SHOULD NOT」「RECOMMENDED」「MAY」及び「OPTIONAL」は、RFC 2119 の定義に従って解釈するものとする。

(訳註：「MUST必須」「MUST NOT必須」「REQUIRED必須」「SHALL必須」「SHALL NOT必須」「SHOULD要請」「SHOULD NOT要請」「RECOMMENDED要請」「MAY任意」「OPTIONAL任意」。「必須」は「〜しなければならない」もしくは「〜してはならない」。「要請」は「〜するものとする」「〜すべきである」「〜しないものとする」。「任意」は「〜してもよい」「〜することができる」「〜する可能性がある」。)

「Window Manager」(ウィンドウ・マネージャ)というキー・ワードは、この仕様書の仕様を採用しているウィンドウ・マネージャを意味する。「Pager」(ページャ)という語はデスクトップのユーティリティ・アプリケーションを指し、これにはページャ(pager)とタスクバー(taskbar)が含まれる。「Application」は、上記のもの以外のクライアントを指す。「Client」は「Pager」と「Application」を指す、即ち「Window Manager」を除く全ての X クライアントを指す。

(訳註：「モニター」は物理的な装置。「screen」は、モニター画面ではない抽象的なスクリーンを指すこともあるし、モニター画面のことを指すこともある。「a screen -> the ~~ screen」は抽象的なスクリーン、最初から「the (~~) screen」はモニター画面のこと。「strut」は、「柱」「矩形」。「cardinal」は「整数」と訳した。要確認・要修正。)

この仕様書に従おうとするウィンドウ・マネージャとクライアントは、ICCCM を遵守しなければならない。この仕様書は ICCCM に基づくものだからである。この仕様書が明確に ICCCM の規約を修正する場合、ウィンドウ・マネージャとクライアントは同修正に従わなければならない。

ICCCM は、同規約では定義してないウィンドウ状態を追加して実装することを認めている。追加のウィンドウ状態は、クライアントからは NormalState や IconicState の下位の状態のように見える。よく見かける例は、最大化(Maximized)と巻き上げ(Shaded)の２つである。ウィンドウ・マネージャは、これらの状態を正式に NormalState と IconicState の下位状態として実装することもできるし、そうした状態を独立のフラグのように扱うこともできる。後者のやり方では、最大化されたウィンドウをアイコン化し、同ウィンドウのアイコン状態を解除する際に再び最大化された状態で表示するということが可能になる。

ICCCM の WM_TRANSIENT_FOR ヒントを使えば、クライアントは次のことを規定することができる。即ち、ある最上位ウィンドウがクライアント自身の終了を待たずに閉じられる可能性があることを規定することができる。一時的な(transient)ウィンドウの典型例はダイアログである。ダイアログの中には、ユーザがメイン・ウィンドウで作業をし続けていても問題なく開いていられるものが存在する。一方、ダイアログが閉じた後でないとユーザがメイン・ウィンドウで作業を続けることができない類のダイアログも存在する。この属性(property)をモダリティ(modality)と呼ぶ。クライアントは「globally active input model」を使用すれば ICCCM に則ったやり方でモーダル・ウィンドウ(modal window)を実装することができるのであるが、一部のウィンドウ・マネージャはモダリティを扱うための機能を別に用意している。

ウィンドウ・マネージャは、管理しているウィンドウをルート・ウィンドウより大きなデスクトップの上に配置する機能を実装することができる。このような大きなデスクトップにおいては、スクリーンはビューポート(viewport、表示領域、表示窓)として機能する。デスクトップ上のビューポートの位置決めに関して、複数の方針(policy)を実装することができる。即ち、ウィンドウ・マネージャは、ビューポートの位置の変化がスクリーンの大きさを単位としてしか起こらないようにしてもよいし(pagingページング)、ビューポートの自由な移動を認めでもよい(scrollingスクロール)。

「クライアントはウィンドウ・マネージャが稼働していてもいなくても同じように動作するべきである」という ICCCM の原則を守るためには、大きなデスクトップを提供するウィンドウ・マネージャは、クライアントが申告するジオメトリ全てを現在のビューポートの座標系で解釈しなければならない。

大きなデスクトップを実装しているウィンドウ・マネージャは大抵、特定のウィンドウを「ガラスに貼り付いた」状態にするための手段をユーザのために用意している。「ガラスに貼り付いた」状態というのは、ビューポートが移動してもその状態にあるウィンドウがスクリーン上の同じ位置に留まり続けることを言う。

大抵の X サーバは、たった１つのスクリーンしか持ってない。ウィンドウ・マネージャは、このリソースを仮想化して複数のいわゆる「仮想デスクトップ」を提供することができる。「仮想デスクトップ」が複数存在しても、スクリーン上には１度に１つしか表示できない。仮想デスクトップの実装は、実装ごとにその機能にいくらか差異がある。デスクトップの個数が固定されているものもあるし、動的に新たなデスクトップを作成できるものもある。デスクトップの大きさも固定であったり可変であったりする。デスクトップがルート・ウィンドウより大き場合、同デスクトップのビューポート(「大きなデスクトップ」の節を見よ)は独立したものであってもよく、同じ位置に固定されていてもよい。

仮想デスクトップを実装するウィンドウ・マネージャは通常、あるデスクトップから別のデスクトップへクライアントを移動させる手段をユーザに提供する。クライアントが同時に複数のデスクトップの上に存在できるようにしてもよい。

ページャは、ウィンドウ管理の仕事のために特別の UI を提供する。ページャは、小さな長方形を用いて、被管理ウィンドウ群を代表しているデスクトップ(群)の縮小表現を表示する。またページャは、このような縮小表現に対する操作を通じて、ユーザがウィンドウ・マネージャの様々な機能を起動することを可能にしている。典型的な機能は、アクティベーション(activation活性化、「活性化(Activation)」の項を見よ)、移動、重ね順の変更、アイコン化、最大化、閉じる動作である。大きなデスクトップにおいては、ページャはビューポートを移動させる手段を提供することができる。仮想デスクトップにおいては、ページャは、デスクトップからデスクトップへウィンドウを移動させる手段と、「現在のデスクトップ」を変更する手段とを提供することができる。

タスクバーは、ウィンドウ管理の仕事のために、これまた別の UI を提供する。タスクバーは通常、ウィンドウのタイトルと(場合によっては)アイコンとを貼り付けたボタンのリスト(ボタンを並べたもの)によって、クライアントを表示する。このボタンを押すと、ボタンによって表示されていたウィンドウに対してウィンドウ・マネージャが何らかの処理を始める。典型的な処理は、活性化(activation)とアイコン化である。タスクバーが存在する環境では、アイコンの使用は不適当だとされることが多い。なぜかというと、アイコン化されたウィンドウは、既にタスクバーの中に表示されているからである。

X の世界では、「ウィンドウを活性化する」とは同ウィンドウに入力フォーカスを与えることを意味する。対象ウィンドウがアンマップされている場合、活性化できない可能性がある。なぜなら、そのウィンドウは別のデスクトップ上にあるかもしれないからである。したがって、ウィンドウの活性化には、同ウィンドウを現在のデスクトップに移動させたり(あるいは同ウィンドウが存在するデスクトップに切り替えたり)、アイコン化を解除したり、前面に表示したりといった追加の処置が必要になる可能性がある。

ウィンドウ・マネージャの中には、ウィンドウをアイコン化したりアイコン化を解除したりする時に何らかの形でアニメーションを見せるものが存在する。例えば、ウィンドウの角とアイコンの角とを結びつける線を描くものがある。また、アイコンもしくはウィンドウが不透明な状態を保ちつつ、ウィンドウの位置とアイコンの位置とを繋ぐ軌道の上をサイズを変えながら移動するものもある。

Window-in-window MDI(ウィンドウの中にウィンドウがある MDI)は、MS Windows 環境などで使われる Multiple Document Interface である。これを採用したプログラムは、１つだけ最上位ウィンドウを持ち、同ウィンドウの中に作業領域を１つ持ち、その中に文書(document)を開いた下位ウィンドウを複数持つ。こうした下位ウィンドウは、ウィンドウ・マネージャのフレームで装飾され、ルート・ウィンドウに属する普通の最上位ウィンドウのように自身の親ウィンドウの範囲内で操作される。

override-redirect 属性が設定されたウィンドウは、従来のウィンドウ・マネージャには無視されるものの、コンポジット・マネージャ(合成マネージャ)には無視されない。コンポジット・マネージャには全てのウィンドウをスクリーンに描画する責任があり、override-redirect ウィンドウも例外ではない。

コンポジット・マネージャが override-redirect ウィンドウを適切に装飾(たとえば同ウィンドウを反透明にしたり形状を変更したり)できるようにするするために、この仕様書ではクライアントが override-redirect ウィンドウにプロパティを設定して同ウィンドウの機能を明らかにすることを認めている。

ウィンドウ・マネージャの中には、最上位ウィンドウの重ね順を一次元の順序に留めておかず、積み重ねたウィンドウを(順序を持つ)複数の層に再分割するものがある。重ね順の多層化は、実装ごとにその機能に大きな違いがある。層の数が固定されているものもあるし、そうでないものもある。最上位ウィンドウの層が明示されていて直接に変更可能なものもあるし、最上位ウィンドウの明示的でなかったり変更可能でなかったりするプロパティ(たとえばウィンドウの「型」(type))によって同ウィンドウの層が定まるものもある。重ね順が厳格な実装、即ちユーザがウィンドウを前面に浮上させたり背面に下がらせたりするにあたって同ウィンドウの属する層を越えることを許さない実装もあるし、そうでない実装もある。

この仕様書では以下に挙げる事柄を扱う。

この仕様書は、以下のものは扱っていない。

誰がクライアントのプログラムを書いてもスクリーン上での振る舞いが変わらないものになるように、ウィンドウ・マネージャがウィンドウ管理方針(policy)に責任を持つことになっている。

この仕様書では、ウィンドウ・マネージャの動作に関する外部操作を多数用意している。これは主に、ページャ、タスクバー及びそれらに似たウィンドウ・マネージャの UI を別個のクライアントとして実装できるようにするためである。 「通常の」クライアントは、ユーザの直接の要請(最大化された状態で開始されるよう「config option」を設定、あるいは「-desk n」のコマンドライン引数を指定)(訳註：要確認)に応える場合を除いて、そうした機能を用いないものとする。

_NET_SUPPORTED, ATOM[]/32

このプロパティは、ウィンドウ・マネージャがどのヒントに対応しているのかを明らかにするために、ウィンドウ・マネージャによって設定されなければならないものである。例：_NET_WM_STATE の場合、このアトム(_NET_WM_STATE)とウィンドウ・マネージャが対応している全ての状態(例えば _NET_WM_STATE_MODAL、_NET_WM_STATE_STICKY)とが列挙される。この仕組みは次のことを想定している。即ち、各ヒントには、名前を変更せずに後方互換でない変更が加えられることはないものと想定している。

_NET_CLIENT_LIST, WINDOW[]/32
_NET_CLIENT_LIST_STACKING, WINDOW[]/32

この２つの配列には、ウィンドウ・マネージャによって管理されている X ウィンドウ全てが入っている。_NET_CLIENT_LIST は最初にマップされた順で並べられており、先頭はもっとも古いウィンドウである。_NET_CLIENT_LIST_STACKING は重ね順であり、背面から前面の順で並べられている。この２つのプロパティは、ウィンドウ・マネージャによって設定され更新されるものとする。

_NET_NUMBER_OF_DESKTOPS, CARDINAL/32

このプロパティは、仮想デスクトップの数を明らかにするために、ウィンドウ・マネージャによって設定され更新されるものとする。

ページャは、ルート・ウィンドウに _NET_NUMBER_OF_DESKTOPS メッセージを送信して、デスクトップ数の変更を要求することができる。

_NET_NUMBER_OF_DESKTOPS
  message_type = _NET_NUMBER_OF_DESKTOPS
  format = 32
  data.l[0] = デスクトップの新たな個数
  残りの data.l[] = 0

ウィンドウ・マネージャはこのリクエストを受け入れてもよいし、拒否してもよい。リクエストを受け入れる場合、_NET_NUMBER_OF_DESKTOPS には新たなデスクトップ数を設定しなければならず、_NET_VIRTUAL_ROOTS には新たなデスクトップ数と同数の仮想ルート・ウィンドウ ID を設定しなければならず、加えて _NET_DESKTOP_VIEWPORT と _NET_WORKAREA もそれに応じて変更しなければならない。_NET_DESKTOP_NAMES プロパティは変更せずに済ませてもよい。

デスクトップ数が減って _NET_CURRENT_DESKTOP の数値が使用可能なデスクトップ(の配列の要素番号)の範囲から外れてしまった場合、同プロパティには新たな集合の中の最後尾のデスクトップ(の要素番号)を設定する。クライアントの中、新たな範囲から外れてしまったデスクトップに依然として留まっている者は、新たな集合の中の前記の最後尾のデスクトップに移されなければならない。このようなクライアントの _NET_WM_DESKTOP は、更新しなければならない。

_NET_DESKTOP_GEOMETRY width, height, CARDINAL[2]/32

２つの整数から成る配列であり、全てのデスクトップの共通サイズを表す(ウィンドウ・マネージャが「大きなデスクトップ」に対応してない場合、このサイズは画面の大きさと等しくなる。対応している場合、デスクトップの仮想サイズに等しくなる。)。このプロパティは、ウィンドウ・マネージャが設定するものとする。

ページャは、_NET_DESKTOP_GEOMETRY 型のクライアント・メッセージをルート・ウィンドウに送信することで、デスクトップのジオメトリの変更を要求することができる。

_NET_DESKTOP_GEOMETRY
  message_type = _NET_DESKTOP_GEOMETRY 
  format = 32
  data.l[0] = 幅の新しい値
  data.l[1] = 高さの新しい値
  残りの data.l[] = 0

ウィンドウ・マネージャは、このメッセージを無視することにしてもよい。その場合、_NET_DESKTOP_GEOMETRY プロパティは変更されない。

_NET_DESKTOP_VIEWPORT x, y, CARDINAL[][2]/32

整数の対の配列であり、各デスクトップのビューポートの左上隅を表す。「大きなデスクトップ」に対応してないウィンドウ・マネージャにおいては、この座標は常に (0, 0) に設定しなければならない。

ページャは、_NET_DESKTOP_VIEWPORT 型のクライアント・メッセージをルート・ウィンドウに送信することで、現在のデスクトップのビューポート(の位置)の変更を要求することができる。

_NET_DESKTOP_VIEWPORT
  message_type = _NET_DESKTOP_VIEWPORT
  format = 32
  data.l[0] = new_vx
  data.l[1] = new_vy
  残りの data.l[] = 0

ウィンドウ・マネージャは、このメッセージを無視することにしてもよい。その場合、_NET_DESKTOP_VIEWPORT プロパティは変更されない。

_NET_CURRENT_DESKTOP desktop, CARDINAL/32

現在のデスクトップの番号(index)である。常に 0 以上 _NET_NUMBER_OF_DESKTOPS - 1 以下の整数である。このプロパティは、ウィンドウ・マネージャが設定し更新しなければならない。ページャは、別の仮想デスクトップへの切り替えを望む場合、_NET_CURRENT_DESKTOP 型のクライアント・メッセージをルート・ウィンドウへ送信しなければならない。

_NET_CURRENT_DESKTOP
  message_type = _NET_CURRENT_DESKTOP 
  format = 32
  data.l[0] = 新しい番号
  data.l[1] = タイムスタンプ
  残りの data.l[] = 0

この仕様の古いバージョンに従っているクライアントは、タイムスタンプに 0 を設定する可能性がある。その場合、タイムスタンプのフィールドは無視するものとする。

_NET_DESKTOP_NAMES, UTF8_STRING[]

全ての仮想デスクトップの名前が入る。UTF-8 形式の NULL 文字終端の文字列の配列である[UTF8]。ページャとウィンドウ・マネージャは、このプロパティをいつでも変更することができる。

補足：名前の数は、_NET_NUMBER_OF_DESKTOPS の数と異なっていても構わない。名前の数が _NET_NUMBER_OF_DESKTOPS の数より小さい場合、要素番号の大きなデスクトップは名前を持たない。名前の数が _NET_NUMBER_OF_DESKTOPS の数より大きい場合、_NET_NUMBER_OF_DESKTOPS の数を超える部分の名前は、デスクトップの数が増えた時に備えたものだと見做される。

玄論：名前は、仮想デスクトップの属性としては必須のものではない。したがって、名前が取得可能であっても不可能であっても、仮想デスクトップの機能性には何の影響も無い。名前はユーザによって設定されるものであり、ユーザは予め決まった数のデスクトップに対して名前を設定するであろうから、取得可能なデスクトップの数が変わった場合にこのプロパティの配列を大きくしたり小さくしたりするのは意味が無い。

_NET_ACTIVE_WINDOW, WINDOW/32

現在アクティブな(入力フォーカスを持つ)ウィンドウのウィンドウ ID が入る。フォーカスを持つウィンドウが存在しない場合、 None が入る。これは読み込み専用のプロパティであり、ウィンドウ・マネージャが設定する。クライアントは、別のウィンドウを活性化したい場合、_NET_ACTIVE_WINDOW 型のクライアント・メッセージをルート・ウィンドウへ送信しなければならない。

_NET_ACTIVE_WINDOW
  window  = 活性化するウィンドウ
  message_type = _NET_ACTIVE_WINDOW
  format = 32
  data.l[0] = source indication(送信元の種別)
  data.l[1] = タイムスタンプ
  data.l[2] = 要求者所有の現在アクティブなウィンドウ、存在しなければ 0 を入れる
  data.l[] の他の要素 = 0

「source indication」(送信元の種別)には、リクエストがアプリケーションから送られる場合は 1 を、ページャから送られる場合は 2 を設定するものとする。この仕様の古いバージョンに従っているクライアントは、送信元の種別として 0 を指定する。詳しくは「リクエストの送信元の種別のヒント」の項を参照。data.l[1] のタイムスタンプは、リクエストの時点でクライアントが記録しているユーザの最後の活動のタイムスタンプ(_NET_WM_USER_TIME を見よ)である。data.l[2] の現在アクティブなウィンドウとは、存在するとすれば、クライアントのアクティブな最上位ウィンドウである(「存在するとすれば」に関して。このリクエストがあるアクティブウィンドウから別のウィンドウへとフォーカスを移すものである場合、ウィンドウ・マネージャがこのリクエストに従う可能性は高くなる。)。

このメッセージの情報次第で、ウィンドウ・マネージャはリクエストを断る可能性がある(完全にリクエストを無視したり、あるいは _NET_WM_STATE_DEMANDS_ATTENTION を使ったりする)。

_NET_WORKAREA, x, y, width, height CARDINAL[][4]/32

このプロパティは、ウィンドウ・マネージャが各デスクトップの作業領域(work area)を計算した上で設定しなければならない。各デスクトップに対して１つづつジオメトリが入っている。これらのジオメトリは、各デスクトップのビューポートに対する相対座標で指定され、完全に同ビューポート内に収まるような領域を指定する。作業領域は、デスクトップ・アプリケーションがデスクトップ・アイコンを適切に設置するために使用するものとする。

ウィンドウ・マネージャが作業領域を計算するには、クライアント・ウィンドウに設定するプロパティである _NET_WM_STRUT もしくは _NET_WM_STRUT_PARTIAL に指定されている通りに、現在のページからドックとパネルのウィンドウのある領域を除く方法によるものとする。

_NET_SUPPORTING_WM_CHECK, WINDOW/32

ウィンドウ・マネージャは、このプロパティをルート・ウィンドウに設置し、同プロパティに自身が作成した子ウィンドウの ID を格納しなければならない。これによって、規約に則ったウィンドウ・マネージャが稼働中であることを示す。当の子ウィンドウも、子ウィンドウ自身のウィンドウ ID が入った _NET_SUPPORTING_WM_CHECK プロパティを持たなければならない。また、この子ウィンドウは、ウィンドウ・マネージャの名前を格納した _NET_WM_NAME プロパティを持たなければならない。

玄論：子ウィンドウは、アクティブなウィンドウ・マネージャを見分けるのに使用する。(子ウィンドウの)古くなった _NET_SUPPORTING_WM_CHECK プロパティは、(ルート・ウィンドウのものとは)別のウィンドウを指すからである。子ウィンドウ上に _NET_SUPPORTING_WM_CHECK プロパティが存在しなかったり、同プロパティが適切に設定されてなかったりした場合、クライアントは、規約に従っているウィンドウ・マネージャは存在しないものと判断するべきである。(訳註：英文の意味がわからなかった。要確認。「distinguish A from B？」「the _NET_SUPPORTING_WM_CHECK window？ on the client？ window」 原文：The child window is used to distinguish an active Window Manager from a stale _NET_SUPPORTING_WM_CHECK property that happens to point to another window.)

_NET_VIRTUAL_ROOTS, WINDOW[]/32

ウィンドウ・マネージャの中には、仮想デスクトップを実現する際、クライアント・ウィンドウの親をルート・ウィンドウの子に変更するものがある。この手法を用いるウィンドウ・マネージャは、仮想ルート・ウィンドウとして振る舞うウィンドウ群の ID の配列をこのプロパティに設定しなければならない。このプロパティのおかげで、背景を設定するプログラムは仮想ルートと協働できるようになり、クライアントは自身のウィンドウに対してウィンドウ・マネージャが与えたフレーム・ウィンドウを認識できるようになる。

_NET_DESKTOP_LAYOUT, orientation, columns, rows, starting_corner CARDINAL[4]/32

  #define _NET_WM_ORIENTATION_HORZ 0
  #define _NET_WM_ORIENTATION_VERT 1

  #define _NET_WM_TOPLEFT     0
  #define _NET_WM_TOPRIGHT    1
  #define _NET_WM_BOTTOMRIGHT 2
  #define _NET_WM_BOTTOMLEFT  3

このプロパティはページャが設定するものであり、ウィンドウ・マネージャが設定するものではない。このプロパティを設定する場合、ページャはマネージャ・セレクション(ICCCM 2.8 で定義)を所有しなければならない。このマネージャ・セレクションの名前は _NET_DESKTOP_LAYOUT_Sn であり、n はスクリーンの番号である。このプロパティの目的は、ページャが表示しているデスクトップ・レイアウトをウィンドウ・マネージャが知ることができるようにすることである。

_NET_DESKTOP_LAYOUT は、仮想デスクトップのレイアウト(仮想デスクトップ同士の位置関係)を記述するものである。より正確に言えば、マネージャ・セレクションの所有者が使用しているレイアウトを記述するものである。ウィンドウ・マネージャは、このレイアウトの情報を利用してもよいし、無視することにしてもよい。このプロパティには４つの値が入る：ページャがデスクトップを並べる方向(orientation水平か垂直)、X 方向のデスクトップの数、Y 方向のデスクトップの数、レイアウトを開始する隅、即ち先頭のデスクトップが来る隅の位置(右上、左下など)。

補足：この文書の古い草案に従って実装されているページャとやり取りするために、ウィンドウ・マネージャは、長さ 3 の配列を持つ _NET_DESKTOP_LAYOUT プロパティをも受け入れるものとし、その場合には「starting_corner」(始まりの隅)として _NET_WM_TOPLEFT を使用するものとする。

仮想デスクトップ群は、rows 個の行と columns 個の列から成る長方形の中に配置される。rows ✕ columns の値が _NET_NUMBER_OF_DESKTOPS で指定されたデスクトップの総数より小さい場合、rows ✕ columns の値を超える番号を持つ作業空間(workspaces)は存在しないものと見做される(訳註：翻訳、要確認)。rows もしくは columns のどちらか(両方ではない)に 0 を指定することは可能だが、その場合、同フィールドの実際の値は _NET_NUMBER_OF_DESKTOPS から導き出すことになる。

orientation (並べる方向)が _NET_WM_ORIENTATION_HORZ (水平)であれば、先頭のデスクトップを starting_corner (右下、左上など)で指定された位置に配置し、そこから横方向にデスクトップを並べていく。３行４列で _NET_WM_TOPLEFT の隅(左上)から始まるレイアウトは、下図のようになる。

 +--+--+--+--+
 | 0| 1| 2| 3|
 +--+--+--+--+
 | 4| 5| 6| 7|
 +--+--+--+--+
 | 8| 9|10|11|
 +--+--+--+--+

starting_corner が _NET_WM_BOTTOMRIGHT (右下)であれば、下図のようになる。

 +--+--+--+--+
 |11|10| 9| 8|
 +--+--+--+--+
 | 7| 6| 5| 4|
 +--+--+--+--+
 | 3| 2| 1| 0|
 +--+--+--+--+

orientation (並べる方向)が _NET_WM_ORIENTATION_VERT (垂直)であれば、３行４列で _NET_WM_TOPLEFT の隅(左上)から始まるレイアウトは、下図のようになる。

 +--+--+--+--+
 | 0| 3| 6| 9|
 +--+--+--+--+
 | 1| 4| 7|10|
 +--+--+--+--+
 | 2| 5| 8|11|
 +--+--+--+--+

starting_corner が _NET_WM_TOPRIGHT (右上)であれば、下図のようになる。

 +--+--+--+--+
 | 9| 6| 3| 0|
 +--+--+--+--+
 |10| 7| 4| 1|
 +--+--+--+--+
 |11| 8| 5| 2|
 +--+--+--+--+

上の図の数字は、_NET_CURRENT_DESKTOP で使われるデスクトップの番号である。

_NET_SHOWING_DESKTOP desktop, CARDINAL/32

ウィンドウ・マネージャの中には、「デスクトップを表示する」モードを備えるものが存在する。このモードでは、ウィンドウは非表示となり、デスクトップの背景が表示されてフォーカスを得る。ウィンドウ・マネージャは、_NET_SHOWING_DESKTOP ヒントに対応している場合、自分が「デスクトップを表示する」モードであれば同ヒントに 1 を設定しなければならず、自分が同モードでなければ 0 を設定しなければならない。

ページャは、「デスクトップを表示する」モードへ移行したい場合や同モードから抜けたい場合、_NET_SHOWING_DESKTOP 型のクライアント・メッセージをルート・ウィンドウへ送信して変更を要請しなければならない。

_NET_SHOWING_DESKTOP
  message_type = _NET_SHOWING_DESKTOP 
  format = 32
  data.l[0] = boolean 0 or 1
  残りの data.l[] = 0

ウィンドウ・マネージャは、このクライアント・メッセージを無視することにしてもよい。

_NET_CLOSE_WINDOW

ウィンドウを閉じたいページャは、_NET_CLOSE_WINDOW 型のクライアント・メッセージ・リクエストをルート・ウィンドウへ送信しなければならない。

_NET_CLOSE_WINDOW
  window = 閉じたいウィンドウ
  message_type = _NET_CLOSE_WINDOW
  format = 32
  data.l[0] = タイムスタンプ
  data.l[1] = source indication(送信元の種別)
  残りの data.l[] = 0

ウィンドウ・マネージャは、指定されたウィンドウを閉じるよう試みなければならない。「source indication」については、「リクエストの送信元の種別のヒント」の項を参照。

玄論：ウィンドウ・マネージャは、通常の手続き(プロトコルが選択されていれば WM_DELETE メッセージを送信し、そうでなければ XKillClient を使う)よりももっと上手い手法をとることができる。例えば、時間切れ(time out)を導入してもよい。ソースコードを複写しなくても、ウィンドウ・マネージャは容易に目的を達することができる。

_NET_MOVERESIZE_WINDOW
  window = 移動・サイズ変更したいウィンドウ
  message_type = _NET_MOVERESIZE_WINDOW
  format = 32
  data.l[0] = gravity and flags 
  data.l[1] = x 
  data.l[2] = y
  data.l[3] = width
  data.l[4] = height

data.l[0] の最下位のバイトには、グラヴィティ(gravityウィンドウを寄せる方向)を表す値が入る。この値には、プロパティ WM_SIZE_HINTS.win_gravity で使える値と同じものを使用することができる。即ち、NorthWest (1)、North (2)、NorthEast (3)、West (4)、Center (5)、East (6)、SouthWest (7)、South (8)、SouthEast (9) 及び Static (10) である。グラヴィティの値が 0 の場合、ウィンドウ・マネージャは WM_SIZE_HINTS.win_gravity で指定されたグラヴィティを使用すべきであることを意味する。８番目〜１１番目のビットは、x、y、width、height が存在するか否かを表す。１２番目〜１５番目のビットは送信元(source)を表す(「リクエストの送信元の種別のヒント」を見よ)。ここでは、「0001」がアプリケーションを表し、「0010」がページャやタスクバーを表す。残りのビットには 0 を設定するものとする。

ウィンドウを移動したりウィンドウのサイズを変更したりしたいページャは、ConfigureRequest を使用する代わりに、_NET_MOVERESIZE_WINDOW 型のクライアント・メッセージ・リクエストをルート・ウィンドウへ送信することもできる。

ウィンドウ・マネージャは、_NET_MOVERESIZE_WINDOW メッセージを ConfigureRequest と全く同じように扱うものとする(特に代用の(synthetic) ConfigureNotify イベントに関する ICCCM の規則に忠実に)。但し、グラヴィティはメッセージで指定されたものを使用するものとする。

玄論：StaticGravity を指定した _NET_MOVERESIZE_WINDOW メッセージを利用することで、ページャは、ウィンドウの装飾の大きさを知ることなく、同装飾を加味した正確な位置と大きさにウィンドウを構成することができるようになる。

_NET_WM_MOVERESIZE
  window = 移動・サイズ変更したいウィンドウ
  message_type = _NET_WM_MOVERESIZE
  format = 32
  data.l[0] = x_root 
  data.l[1] = y_root
  data.l[2] = direction
  data.l[3] = button
  data.l[4] = source indication(送信元の種別)

このメッセージを使って、クライアントはウィンドウの移動もしくはサイズ変更を開始することができる。クライアントは、移動とサイズ変更の実際の操作をウィンドウ・マネージャの手に委ねながらも、独自の移動と独自のサイズ変更の「寄せる方向」(grips)とを定義することができる。これは、移動とサイズ変更の全てがウィンドウ・マネージャによって定められたやり方と矛盾しない形で実施されることを意味する。source indication については、「リクエストの送信元の種別のヒント」を参照。

このメッセージがボタン押下イベントに応じて送信される場合、button には押されたボタンを指定するべきであり、x_root と y_root にはルート・ウィンドウの座標空間におけるボタン押下の位置を指定しなければならず、direction には移動イベントとサイズ変更イベントのどちらであるかを指定しなければならず、またサイズ変更イベントである場合は、(direction には)サイズ変更の際の寄せる方向がウィンドウの端のどちらなのかを指定しなければならない。このメッセージがキー・イベントに応じて送信される場合、direction には移動イベントなのかそれともサイズ変更イベントなのかを指定しなければならず、他のフィールドは使わない。

#define _NET_WM_MOVERESIZE_SIZE_TOPLEFT      0
#define _NET_WM_MOVERESIZE_SIZE_TOP          1
#define _NET_WM_MOVERESIZE_SIZE_TOPRIGHT     2
#define _NET_WM_MOVERESIZE_SIZE_RIGHT        3
#define _NET_WM_MOVERESIZE_SIZE_BOTTOMRIGHT  4
#define _NET_WM_MOVERESIZE_SIZE_BOTTOM       5
#define _NET_WM_MOVERESIZE_SIZE_BOTTOMLEFT   6
#define _NET_WM_MOVERESIZE_SIZE_LEFT         7
#define _NET_WM_MOVERESIZE_MOVE              8   /* 移動のみ */
#define _NET_WM_MOVERESIZE_SIZE_KEYBOARD     9   /* キーボードによるサイズ変更 */
#define _NET_WM_MOVERESIZE_MOVE_KEYBOARD    10   /* キーボードによる移動 */
#define _NET_WM_MOVERESIZE_CANCEL           11   /* 取り消し操作 */

クライアントは、これらのメッセージ(_NET_WM_MOVERESIZE_CANCEL メッセージを除く)を送信する前に、全ての占有を解除しなければならない。

ウィンドウ・マネージャは、button フィールドを利用することによって、_NET_WM_MOVERESIZE メッセージから始まった操作を終了する際の切っ掛けとなるイベントを決定することができる。_NET_WM_MOVERESIZE メッセージを送信したクライアントとボタンを離したユーザとの間には競合条件が存在するので、ウィンドウ・マネージャは、上記操作を終了する何か別の手段も用意しておくことが望ましい(ESC キーを押すなど)。クライアントは、ボタンから手が離れたのを自分で検知した場合に、_NET_WM_MOVERESIZE_CANCEL という特別な値を用いたメッセージを送信することで、上記の操作を取り消すことができる(クライアントは、移動・サイズ変更のメッセージを送信した後にボタン押下解除を知った場合、この取り消しメッセージを送信するべきである。これは、ウィンドウ・マネージャの占有取得がボタン押下解除に間に合わなかったことを示す)。

_NET_RESTACK_WINDOW

ウィンドウの重ね順を変更したいページャは、_NET_RESTACK_WINDOW 型のクライアント・メッセージ・リクエストをルート・ウィンドウへ送信するものとする。

_NET_RESTACK_WINDOW
  window = 重ね順を変えたいウィンドウ
  message_type = _NET_RESTACK_WINDOW
  format = 32
  data.l[0] = source indication(送信元の種別)
  data.l[1] = 兄弟ウィンドウ
  data.l[2] = detail
  残りの data.l[] = 0

このリクエストは、CWSibling フラグと CWStackMode フラグとが設定された ConfigureRequest によく似ている。このリクエストはページャ専用とすべきであり、通常のアプリケーションは普通の ConfigureRequest を使う。それゆえ source indication フィールドには 2 を指定するものとする。詳しくは「リクエストの送信元の種別のヒント」を参照。

玄論：ウィンドウ・マネージャは、アプリケーションからの構成変更要求(configure requests)に対して制限を加えることができる。例えば、特定の状況においてウィンドウの前面への移動を拒否することができる。このリクエストはページャかそれに類するツールから送られて来るのが明らかなので、ウィンドウ・マネージャは常にこれに従うべきである。

_NET_REQUEST_FRAME_EXTENTS
  window = _NET_FRAME_EXTENTS プロパティが設定されているウィンドウ
  message_type = _NET_REQUEST_FRAME_EXTENTS

ウィンドウがまだマップされてないクライアントは、自分がマップ時に与えられるフレームの幅の見積もりをウィンドウ・マネージャに対して要求することができる。このような見積もりを得るためには、クライアントは _NET_REQUEST_FRAME_EXTENTS 型のメッセージをルート・ウィンドウへ送信しなければならない。ウィンドウ・マネージャは、あるべきフレームの幅を見積もり、その結果を指定されたウィンドウの _NET_FRAME_EXTENTS プロパティに設定することによって、先のメッセージに応えなければならない。クライアントは、その結果として生ずる _NET_FRAME_EXTENTS の PropertyNotify イベントを処理しなければならない。ウィンドウ・マネージャに対して見積もりのためのしっかりした根拠を与えるために、クライアントは、設定するつもりであるウィンドウ・プロパティ全てを設定し終えてから、このメッセージを送信しなければならない。クライアントは、不完全な見積もりにも上手く対応できなければならない。

玄論：クライアントは、ウィンドウがマップされるまでは自身のウィンドウのフレームの面積を計算することができない。しかし、一部のツールキットはこの情報を必要とする。ウィンドウ・マネージャに幅の見積もりを尋ねることは、現実的な解決方法の１つである。見積もりの結果は、現在のテーマ、フォント・サイズ、及び他のウィンドウ・プロパティによって変わり得る。クライアントは、_NET_FRAME_EXTENTS の PropertyNotify イベントを看視することで、フレームの面積の変化を追跡することができる。

_NET_WM_NAME, UTF8_STRING

クライアントはこのプロパティに UTF-8 形式でウィンドウのタイトルを設定する。このプロパティが設定されている場合、ウィンドウ・マネージャはこれを WM_NAME より優先して使用するものとする。

_NET_WM_VISIBLE_NAME, UTF8_STRING

ウィンドウ・マネージャは、_NET_WM_NAME とは異なるウィンドウ名(タイトル)を表示する場合、表示すべきタイトルを UTF-8 形式でこのプロパティに設定しなければならない。

玄論：このプロパティは次のようなウィンドウ・マネージャのために存在する。即ち、ウィンドウの _NET_WM_NAME や WM_NAME とは異なるタイトルを表示し(例：xterm <1>、xterm <2> と表示されるが、各ウィンドウの _NET_WM_NAME と WM_NAME は依然として xterm である)、それによってページャがウィンドウ・マネージャと同じタイトルを表示できるようにするようなウィンドウ・マネージャのために存在する。

_NET_WM_ICON_NAME, UTF8_STRING

クライアントは、ウィンドウのアイコンのタイトルを UTF-8 形式でこのプロパティに設定するものとする。このプロパティが設定されている場合、ウィンドウ・マネージャはこれを WM_ICON_NAME より優先して使用するものとする。

_NET_WM_VISIBLE_ICON_NAME, UTF8_STRING

ウィンドウ・マネージャは、_NET_WM_ICON_NAME とは異なるアイコン名(タイトル)を表示する場合、表示すべきタイトルを UTF-8 形式でこのプロパティに設定しなければならない。

_NET_WM_DESKTOP desktop, CARDINAL/32

ウィンドウが存在する(あるいはそのように望む)デスクトップを表す整数が入る。0 から始まり、0 は先頭のデスクトップを表す。クライアントは、このプロパティを設定しないことにしてもよい。その場合、ウィンドウ・マネージャは好きな値を入れて同プロパティを設置するものとする。0xFFFFFFFF は、当該ウィンドウが全てのデスクトップで表示されるべきことを意味する。

ウィンドウ・マネージャは、Withdrawn 状態のウィンドウをマップするよう要求された時は常に、_NET_WM_DESKTOP プロパティをそのまま受け入れるものとする。

ウィンドウ・マネージャは、ウィンドウが引っ込む(withdraw)時は常にこのプロパティを削除するものとする。一方、WM_Sn マネージャ・セレクションの所有権を失う等して、ウィンドウ・マネージャが終了する(shut down)場合には、同者はこのプロパティをそのまま残しておくものとする。

玄論：ウィンドウを引っ込める(withdraw)際にこのプロパティを削除するのは、Withdrawn 状態のウィンドウを再利用しようとする古いアプリケーションに対応するためである。ウィンドウ・マネージャの終了時(upon shutdown)にこのプロパティを削除しないのは、次のウィンドウ・マネージャがウィンドウ群を以前あったデスクトップに復元できるようにするためである。

クライアントは、_NET_WM_DESKTOP 型のクライアント・メッセージをルート・ウィンドウへ送信することによって、Withdrawn 状態でないウィンドウのデスクトップの変更を要求することができる。

_NET_WM_DESKTOP
  window  = 対象のクライアント・ウィンドウ
  message_type = _NET_WM_DESKTOP
  format = 32
  data.l[0] = new_desktop
  data.l[1] = source indication
  残りの data.l[] = 0

source indication の詳細については「リクエストの送信元の種別のヒント」を見よ。ウィンドウ・マネージャは、全てのウィンドウのこのプロパティを最新状態に保たなければならない。

_NET_WM_WINDOW_TYPE, ATOM[]/32

このプロパティは、マップされる前のクライアントによって設定されるものとし、内容はウィンドウの機能の型(type)を表すアトムの配列である。このプロパティは、ウィンドウ・マネージャによって利用され、ウィンドウの装飾、積み重ねの順番、及びその他の振る舞いを決めるのに使われる。クライアントは、優先度の高い順(先頭の値が最も優先度が高い)にウィンドウの型を指定するべきであるが、下に列挙した基本となるウィンドウの型を表すアトムの中、少なくとも１つを含めなければならない。これによって、ウィンドウの型の目録の拡張を可能にしつつ、そのような拡張を認識しないウィンドウ・マネージャのためにデフォルトの振る舞いを用意しておくことができる。

このヒントは、コンポジット・マネージャが統一された装飾をメニューやツールチップ(tooltips)等に施せるように、override-redirect ウィンドウにも設定するものとする。

玄論：このヒントは MOTIF のヒントの代替物として作られた。MOTIF のヒントの難点(の１つ)は、同ヒントが単にウィンドウの装飾の見た目を記述するものにすぎなかったことである。ウィンドウの機能を記述することによって、ウィンドウ・マネージャは同じ型のウィンドウに対して同じ装飾と同じ振る舞いを与えられるようになった。振る舞いの例としては、ドックやパネルを最前面に表示し続けること、あるいはピン留め可能なメニューやツールバーを他のウィンドウがフォーカスを得た時だけ隠れるようにすること(NextStep 方式)が挙げられよう。

_NET_WM_WINDOW_TYPE_DESKTOP, ATOM
_NET_WM_WINDOW_TYPE_DOCK, ATOM
_NET_WM_WINDOW_TYPE_TOOLBAR, ATOM
_NET_WM_WINDOW_TYPE_MENU, ATOM
_NET_WM_WINDOW_TYPE_UTILITY, ATOM
_NET_WM_WINDOW_TYPE_SPLASH, ATOM
_NET_WM_WINDOW_TYPE_DIALOG, ATOM
_NET_WM_WINDOW_TYPE_DROPDOWN_MENU, ATOM
_NET_WM_WINDOW_TYPE_POPUP_MENU, ATOM
_NET_WM_WINDOW_TYPE_TOOLTIP, ATOM
_NET_WM_WINDOW_TYPE_NOTIFICATION, ATOM
_NET_WM_WINDOW_TYPE_COMBO, ATOM
_NET_WM_WINDOW_TYPE_DND, ATOM
_NET_WM_WINDOW_TYPE_NORMAL, ATOM

_NET_WM_WINDOW_TYPE_DESKTOP はデスクトップ機能を表す。この値は、デスクトップ・アイコンを持つ単一のウィンドウであって、画面と同一の面積を持つものに設定することができる。これによってデスクトップ環境は、ルート・ウィンドウへのクリックを途中で押さえなくても、デスクトップの完全な制御を得ることができる。

_NET_WM_WINDOW_TYPE_DOCK はドックまたはパネルの機能を表す。通常、ウィンドウ・マネージャはそのようなウィンドウを他の全てのウィンドウより前に表示し続ける。

_NET_WM_WINDOW_TYPE_TOOLBAR と _NET_WM_WINDOW_TYPE_MENU はそれぞれ、ツールバーとピン留め可能なメニューのウィンドウを表す(即ち、主たるアプリケーションから切り離されたツールバーとメニューを表す)。この種のウィンドウには、主たるアプリケーション・ウィンドウを指し示す WM_TRANSIENT_FOR ヒントを設定することができる。_NET_WM_WINDOW_TYPE_MENU は、切り離されていて且つ(ウィンドウ・マネージャによって)管理されているウィンドウに設定すべきものであり、通常 override-redirect ウィンドウで使用される _NET_WM_WINDOW_TYPE_DROPDOWN_MENU 及び _NET_WM_WINDOW_TYPE_POPUP_MENU とはこの点が異なっている。

_NET_WM_WINDOW_TYPE_UTILITY は、パレットやツールボックスのような、小さくて長時間存続するユーティリティ・ウィンドウを表す。これはツールバーとは型が異なる。主たるアプリケーションから切り離されたツールバーに相当するものではないからである。ダイアログとも型が違う。一時的な(transient)なダイアログではなく、ユーザは作業を続けている限りそのウィンドウを開いたままにするであろうからである。この種のウィンドウには、主たるアプリケーション・ウィンドウを指し示す WM_TRANSIENT_FOR ヒントを設定することができる。

_NET_WM_WINDOW_TYPE_SPLASH は、ウィンドウがアプリケーション起動時に表示されるスプラッシュ・スクリーンであることを表す。

_NET_WM_WINDOW_TYPE_DIALOG は、ウィンドウがダイアログ・ウィンドウであることを表す。_NET_WM_WINDOW_TYPE が設定されてない場合、ウィンドウ・マネージャに管理されているウィンドウの中の WM_TRANSIENT_FOR が設定されているものは、_NET_WM_WINDOW_TYPE_DIALOG 型と見做されなければならない。override-redirect ウィンドウの中、WM_TRANSIENT_FOR プロパティは設定されているが _NET_WM_WINDOW_TYPE プロパティは設定されていないものは、_NET_WM_WINDOW_TYPE_NORMAL 型と見做されなければならない。

_NET_WM_WINDOW_TYPE_DROPDOWN_MENU は、そのウィンドウがドロップダウン・メニューであることを表す。ドロップダウン・メニューは、ユーザがメニューバーをクリック(左クリック)した時に(通常)現れる類のメニューであり、ユーザがあるオブジェクトを右クリックした時に(通常)現れるポップアップ・メニューと対を成すものである。このプロパティは通常、override-redirect ウィンドウで使用される。

_NET_WM_WINDOW_TYPE_POPUP_MENU は、そのウィンドウがポップアップ・メニューであることを表す。ポップアップ・メニューは、ユーザがあるオブジェクトを右クリックした時に(通常)現れる類のメニューであり、ユーザがメニューバーをクリック(左クリック)した時に(通常)現れるドロップダウン・メニューと対を成すものである。このプロパティは通常、override-redirect ウィンドウで使用される。

_NET_WM_WINDOW_TYPE_TOOLTIP は、そのウィンドウがツールチップ(tooltip)であることを表す。ツールチップは、マウス・カーソルがあるオブジェクトの上にしばらく滞在した時に(通常)現れる、短い説明テキストのことである。このプロパティは通常、override-redirect ウィンドウで使用される。

_NET_WM_WINDOW_TYPE_NOTIFICATION は、通知を表す。通知の一例を挙げると、「ラップトップの電源が切れています」といった情報テキストを表示するバブル(bubble)がある。このプロパティは通常、override-redirect ウィンドウで使用される。

_NET_WM_WINDOW_TYPE_COMBO は、コンボ・ボックスによってポップ・アップするウィンドウで使用するものとする。一例を挙げると、テキスト入力欄の下に現れるウィンドウであって、入力の補完候補の一覧を表示するものがある。このプロパティは通常、override-redirect ウィンドウで使用される。

_NET_WM_WINDOW_TYPE_DND は、そのウィンドウがドラッグされていることを表す。クライアントは、そのウィンドウの中に、ある場所から別の場所へドラッグされているオブジェクトを表現したものが含まれている場合、このヒントを設定すべきである。一例を挙げると、あるファイル・マネージャ・ウィンドウから別のファイル・マネージャ・ウィンドウへドラッグされているアイコンを含むウィンドウがある。このプロパティは通常、override-redirect ウィンドウで使用される。

_NET_WM_WINDOW_TYPE_NORMAL は、そのウィンドウが普通の最上位ウィンドウであることを表す。ウィンドウ・マネージャに管理されていても、override-redirect 属性があってもかまわない。 ウィンドウ・マネージャに管理されていながら _NET_WM_WINDOW_TYPE も WM_TRANSIENT_FOR も設定されていないウィンドウは、この型(_NET_WM_WINDOW_TYPE_NORMAL)のウィンドウだと見做されなければならない。_NET_WM_WINDOW_TYPE プロパティを持たない override-redirect ウィンドウは、WM_TRANSIENT_FOR が設定されているか否かに関わらず、この種類のウィンドウだと見做されなければならない。

      _NET_WM_STATE, ATOM[]

ウィンドウの状態を示すヒントの配列である。配列にあるアトムは「設定されているもの」と見做されなければならず、配列に入ってないアトムは「設定されていないもの」と見做されなければならない。ウィンドウ・マネージャは、Withdrawn 状態のウィンドウがマップを要求した時は常に、_NET_WM_STATE の値をそのまま受け入れるものとする。ウィンドウの状態を変更したいクライアントは、_NET_WM_STATE 型のクライアント・メッセージをルート・ウィンドウへ送信しなければならない(後ほど説明)。ウィンドウ・マネージャは、ウィンドウの現在の状態を反映するようにこのプロパティを最新状態に保たなければならない。

ウィンドウ・マネージャは、ウィンドウが Withdrawn 状態になった時は常に、このプロパティを削除するものとする。一方、WM_Sn マネージャ・セレクションの所有権を失う等してウィンドウ・マネージャが終了する(shut down)時は、同者はこのプロパティをそのまま残しておくものとする。

玄論：ウィンドウを引っ込める(withdraw)際にこのプロパティを削除するのは、Withdrawn 状態のウィンドウを再利用しようとする古いアプリケーションに対応するためである。ウィンドウ・マネージャの終了時(upon shutdown)にこのプロパティを削除しないのは、次のウィンドウ・マネージャがウィンドウ群を以前の状態に復元できるようにするためである。

使用できるアトムは以下のものである。

_NET_WM_STATE_MODAL, ATOM
_NET_WM_STATE_STICKY, ATOM
_NET_WM_STATE_MAXIMIZED_VERT, ATOM
_NET_WM_STATE_MAXIMIZED_HORZ, ATOM
_NET_WM_STATE_SHADED, ATOM
_NET_WM_STATE_SKIP_TASKBAR, ATOM
_NET_WM_STATE_SKIP_PAGER, ATOM
_NET_WM_STATE_HIDDEN, ATOM
_NET_WM_STATE_FULLSCREEN, ATOM
_NET_WM_STATE_ABOVE, ATOM
_NET_WM_STATE_BELOW, ATOM
_NET_WM_STATE_DEMANDS_ATTENTION, ATOM
_NET_WM_STATE_FOCUSED, ATOM

実装時に、上の表に新たなアトムを加えてもよい。拡張に対応してない実装においては、未知のアトムはいづれも無視しなければならず、事実上、使用可能なアトムの一覧から未知のアトムを取り除くことになる。拡張によって追加されたアトムは、接頭辞「_NET」から始まるものであってはならない。

_NET_WM_STATE_MODAL は、このウィンドウがモーダル・ダイアログ・ボックスであることを示す。WM_TRANSIENT_FOR が設定されていて他の最上位ウィンドウを指している場合、このダイアログはそのウィンドウに対してのみモーダルとなる。WM_TRANSIENT_FOR の値が None に設定されているかもしくはルート・ウィンドウに設定されている場合、このダイアログは自身のウィンドウ・グループに対してモーダルとなる。

_NET_WM_STATE_STICKY は、仮想デスクトップがスクロールしている場合でも、ウィンドウ・マネージャが画面上のウィンドウの位置を固定し続けるべきであることを表す。

_NET_WM_STATE_MAXIMIZED_{VERT,HORZ} は、そのウィンドウが{垂直に、水平に}最大化されていることを示す。

_NET_WM_STATE_SHADED は、そのウィンドウが巻き上げられていることを示す。

_NET_WM_STATE_SKIP_TASKBAR は、そのウィンドウをタスクバーに入れないようにするべきであることを示す。このヒントは、アプリケーションが設定の要求をするべきものであり、そのウィンドウが元からタスクバーに入らない種類のものであることを示す。_NET_WM_WINDOW_TYPE プロパティに既にウィンドウの正確な種類が設定されている場合、アプリケーションはこのヒントを設定しないものとする。

_NET_WM_STATE_SKIP_PAGER は、そのウィンドウをページャに含めないようにするべきであることを示す。このヒントは、アプリケーションが設定の要求をするべきものであり、そのウィンドウが元からページャの中に含まれない種類のものであることを示す。_NET_WM_WINDOW_TYPE プロパティに既にウィンドウの正確な種類が設定されている場合、アプリケーションはこのヒントを設定しないものとする。

_NET_WM_STATE_HIDDEN は、ウィンドウ・マネージャが設定するべきものであり、次のことを示す。即ち、ウィンドウが存在するデスクトップとビューポートがアクティブであり且つ同ウィンドウの座標が画面の範囲内であったとしても、そのウィンドウを画面に表示しない(可視状態にしない)ことを示す。最小化されたウィンドウは _NET_WM_STATE_HIDDEN 状態にあるべきである。ページャとそれに類するアプリケーションは、デスクトップ上のウィンドウ群の縮小表現(miniature representation)内で特定のウィンドウを表示するか否かを決めるにあたって、WM_STATE ではなく _NET_WM_STATE_HIDDEN を使用するものとする。

実装のための覚え書：アプリケーションが _NET_WM_STATE_HIDDEN 状態(のON/OFF)を切り替えるよう要求した場合、ウィンドウ・マネージャはこの要求を単に無視するべきであろう。なぜかというと、_NET_WM_STATE_HIDDEN は独立した「状態」ではなく、最小化のような、「状態」とは呼べないウィンドウの「様相」(aspect)の機能の１つであるから。

_NET_WM_STATE_FULLSCREEN は、ウィンドウが画面全体に表示され、且つ装飾を持たないようにするべきであることを示す。加えて、フルスクリーン状態から通常のウィンドウに戻った時、ウィンドウ・マネージャには元のジオメトリを復元すべき責任がある。例えば、プレゼンテーション・プログラム(訳註：要確認)はこのヒントを使うであろう。

_NET_WM_STATE_ABOVE は、そのウィンドウを大多数のウィンドウよりも前に表示するべきことを示す(詳しくは「重ね順」の項を見よ)。

_NET_WM_STATE_BELOW は、そのウィンドウを大多数のウィンドウの後ろに表示するべきことを示す(詳しくは「重ね順」の項を見よ)。

_NET_WM_STATE_ABOVE と _NET_WM_STATE_BELOW は、主にユーザが自分の好みを指定する(preference)際に使用することを予定しており、アプリケーションから設定しないようにするべきである。例えば、アプリケーションのダイアログに注意を引きつけるためにアプリケーションから設定したりしないようにするべきである(この場合 Urgency ヒントを使うべきである。「緊急フラグ」の項を参照)。

_NET_WM_STATE_DEMANDS_ATTENTION は、ウィンドウの中で、あるいはウィンドウに対して何らかの動きが生じたことを示す。例えば、ウィンドウが活性化を要求したけれどもウィンドウ・マネージャがそれを拒んだ場合、ウィンドウ・マネージャによってこのアトムが設定されることがあり、また、アプリケーションが何かの作業を終えた場合、同アプリケーションによってこのアトムが設定されることもある。この状態は、クライアントとウィンドウ・マネージャの両方によって設定される可能性がある。ウィンドウ・マネージャは、ウィンドウが必要な「注意」を得たと(通常は、ウィンドウが活性化されたと)判断した場合、この状態設定を解除するものとする。

_NET_WM_STATE_FOCUSED は、ウィンドウの装飾をアクティブ状態の時の形状で描くか否かを示す。クライアントは、これを読み取り専用のヒントと見做さなければならない。このヒントは、マップ時に設定してはいけないし、_NET_WM_STATE クライアント・メッセージを使って変更してもいけない。_NET_ACTIVE_WINDOW を持つウィンドウは通常このヒントも持っているが、時として他のウィンドウもこのヒントを持つことがある。それは、そのウィンドウがアクティブなウィンドウと強い関連を持っており、ユーザが同ウィンドウをアクティブなウィンドウと一体のものだと考える場合である。最上位ウィンドウがキーボード・フォーカスを持っている場合に内部要素の見た目を変更するクライアントは、_NET_SUPPORTED を調べてこの状態(このアトム)が利用可能か確認するものとし、利用可能な場合、FocusIn イベントによってフォーカスを追跡するのではなく、このヒントを使用するものとする。そうすることで内部要素(の見た目)は、ウィンドウの装飾と調和したものになり、ウィンドウ・マネージャの意図を正確に反映したものになる。

マップされているウィンドウの状態を変更するには、クライアントは _NET_WM_STATE 型のクライアント・メッセージをルート・ウィンドウへ送信しなければならない。

  window  = 対象のクライアント・ウィンドウ
  message_type = _NET_WM_STATE
  format = 32
  data.l[0] = 後述する動作のいづれか
  data.l[1] = 変更するプロパティその１
  data.l[2] = 変更するプロパティその２
  data.l[3] = 送信元の種別(source indication)
  残りの data.l[] = 0

このメッセージでは、２つのプロパティを同時に変更することができる。例えば、水平方向の最大化と垂直方向の最大化の両方を同時に切り替えることができる。１つのプロパティしか変更しない場合、data.l[2] には 0 を設定しなければならない。source indication については「リクエストの送信元の種別のヒント」を参照。data.l[0] は、以下のいづれかの動作でなければならない。

_NET_WM_STATE_REMOVE        0    /* プロパティの削除・設定解除を行う */
_NET_WM_STATE_ADD           1    /* プロパティの追加・設定を行う */
_NET_WM_STATE_TOGGLE        2    /* プロパティの ON/OFF を切り替える  */

実装のための覚え書の中の「緊急フラグ」と「固定サイズのウィンドウ」の項も参照。

_NET_WM_ALLOWED_ACTIONS, ATOM[]

ユーザの操作の中、ウィンドウ・マネージャがこのウィンドウへ適用することを認めているものを表すアトムの配列である。配列に含まれているアトムは許可された動作を表し、配列中にないアトムは、このウィンドウに適用することができない動作を表す。ウィンドウ・マネージャは、このプロパティを最新状態に保たなければならず、ウィンドウの現在「アクティブ」な動作や現在「sensitive」(訳註：命令が来ればすぐ実行できるみたいな意味か？要確認)な動作を反映するようにしなければならない。タスクバー、ページャ及びその他のツールは、_NET_WM_ALLOWED_ACTIONS を使って、どの動作がユーザ側から利用可能であるべきなのかを決めることができる。

以下のアトムを指定することができる。

_NET_WM_ACTION_MOVE, ATOM
_NET_WM_ACTION_RESIZE, ATOM
_NET_WM_ACTION_MINIMIZE, ATOM
_NET_WM_ACTION_SHADE, ATOM
_NET_WM_ACTION_STICK, ATOM
_NET_WM_ACTION_MAXIMIZE_HORZ, ATOM
_NET_WM_ACTION_MAXIMIZE_VERT, ATOM
_NET_WM_ACTION_FULLSCREEN, ATOM
_NET_WM_ACTION_CHANGE_DESKTOP, ATOM
_NET_WM_ACTION_CLOSE, ATOM
_NET_WM_ACTION_ABOVE, ATOM
_NET_WM_ACTION_BELOW, ATOM

実装時に、上の表に新たなアトムを加えてもよい。拡張に対応してない実装においては、未知のアトムはいづれも無視しなければならず、事実上、使用可能なアトムの一覧から未知のアトムを取り除くことになる。拡張によって追加されたアトムは、接頭辞「_NET」から始まるものであってはならない。

ここで挙げられた動作(action)は、ウィンドウ・マネージャがこのウィンドウに対しての適用を認めるものにすぎないことに注意。動作を実行するには依然としてウィンドウ・マネージャの操作(operation)を要求する必要があり、操作の要求はこの仕様書で概説されている通常の手続きを通じて為されなければならない。例えば、_NET_WM_ACTION_CLOSE は、クライアントがそのウィンドウに対して WM_DELETE_WINDOW メッセージを送ってよいという意味ではない。_NET_WM_ACTION_CLOSE は、クライアントは _NET_CLOSE_WINDOW メッセージを使ってウィンドウ・マネージャにそうするよう(WM_DELETE_WINDOW メッセージを送るよう)頼んでよいという意味である。

ウィンドウ・マネージャは、ウィンドウの管理を始めたばかりの時は、_NET_WM_ALLOWED_ACTIONS の値を無視するものとする。この値は、別の方針を持つ前任のウィンドウ・マネージャが残していったものかもしれないからである。

_NET_WM_ACTION_MOVE は、ウィンドウが画面上を移動できることを表す。

_NET_WM_ACTION_RESIZE は、ウィンドウのサイズを変更できることを表す。(実装のための覚え書：ウィンドウ・マネージャは、あるウィンドウの WM_NORMAL_HINTS の最小サイズと最大サイズが同じであれば、同ウィンドウがサイズ変更不可能なものであると判断する。)

_NET_WM_ACTION_MINIMIZE は、ウィンドウをアイコン化することができることを表す。

_NET_WM_ACTION_SHADE は、ウィンドウを巻き上げることができることを表す。

_NET_WM_ACTION_STICK は、ウィンドウの固定状態の ON/OFF (_NET_WM_STATE_STICKY の中身)を切り替えることができることを示す。この状態はビューポートに対するものであってデスクトップに対するものではないことに注意。

_NET_WM_ACTION_MAXIMIZE_HORZ は、ウィンドウを水平方向に最大化できることを示す。

_NET_WM_ACTION_MAXIMIZE_VERT は、ウィンドウを垂直方向に最大化できることを示す。

_NET_WM_ACTION_FULLSCREEN は、ウィンドウを全画面表示状態にできることを示す。

_NET_WM_ACTION_CHANGE_DESKTOP は、デスクトップを跨いでウィンドウを移動させることができることを示す。

_NET_WM_ACTION_CLOSE は、ウィンドウを閉じることができる(_NET_CLOSE_WINDOW を送ることができる)ことを示す。

_NET_WM_ACTION_ABOVE は、ウィンドウをウィンドウ群の層の中の上(前面)の層に配置することができることを示す(即ち、_NET_WM_STATE_ABOVE の変更に応じることができる。詳しくは「重ね順」の項を見よ)。

_NET_WM_ACTION_BELOW は、ウィンドウをウィンドウ群の層の中の下(背面)の層に配置することができることを示す(即ち、_NET_WM_STATE_BELOW の変更に応じることができる。詳しくは「重ね順」の項を見よ)。

_NET_WM_STRUT, left, right, top, bottom, CARDINAL[4]/32

このプロパティは、全ての「_start_」の値に 0 を設定し、全ての「_end_」の値に論理スクリーンの高さと幅を設定した _NET_WM_STRUT_PARTIAL プロパティと同じである。_NET_WM_STRUT_PARTIAL は _NET_WM_STRUT より後に導入されたものであるが、クライアントは、この仕様の古い版にしか対応してないウィンドウ・マネージャに対する後方互換性を確保するため、_NET_WM_STRUT_PARTIAL プロパティに加えて _NET_WM_STRUT をも設定することができる。

_NET_WM_STRUT_PARTIAL, left, right, top, bottom, left_start_y, left_end_y,
right_start_y, right_end_y, top_start_x, top_end_x, bottom_start_x,
bottom_end_x,CARDINAL[12]/32

画面の端の空間を確保する必要のあるウィンドウがある場合、クライアントがこのプロパティを設定しなければならない。このプロパティに入るのは、画面の４つの縁それぞれで確保すべき領域の幅を表す４つの整数と、４つの柱(strut画面の端の矩形)それぞれの始めと終わりの位置を表す８つの整数である。プロパティ中の値の並び順は、left、right、top、bottom、left_start_y、left_end_y、right_start_y、right_end_y、top_start_x、top_end_x、bottom_start_x、bottom_end_x の順である。全ての座標は、ルート・ウィンドウの座標系のものである。クライアントは、いつでもこのプロパティを変更することができる。それゆえに、ウィンドウ・マネージャは、このプロパティの内容に従ってウィンドウへ特別な意味を与える場合、PropertyNotify イベントを看視しなければならない。

このプロパティと _NET_WM_STRUT プロパティの両方が設定してある場合、ウィンドウ・マネージャは _NET_WM_STRUT プロパティの値を無視しなければならず、代わりに _NET_WM_STRUT_PARTIAL の値を使用しなければならない。これによってクライアントは、新たなプロパティの拡張された意味(機能)を諦めることなく、安全に両方のプロパティを設定できるようになる。

柱(strut矩形)の役割は、デスクトップの端に領域を確保することである。ドック領域、タスクバーやパネルなどのためにとても役に立つ。ウィンドウ・マネージャは、ウィンドウの位置を制限する場合にこの確保された領域を計算に入れるものとする。例えば、最大化したウィンドウはこの領域には侵入しないものとする。

各矩形の _start_ と _end_ の値のおかげで、画面の幅や高さに満たない長さの領域でも確保できるようになっている。柱(strut矩形)は、ルート・ウィンドウの座標系で座標を指定しなければならならず、ビューポートや Xinerama モニター(のいづれか)の端からの相対座標ではない。

例えば、パネル型のクライアントであって、画面の下に表示され、高さが 50 ピクセルで、画面の左端から 200 ピクセルの位置で始まり 600 ピクセルの位置で終わる領域を占める者は、bottom (の柱)に 50 を設定し、bottom_start_x に 200、bottom_end_x に 600 を指定する。もう１つ、Xinerama 拡張を用いた画面の上にあるパネルの例を挙げる。２つのモニター(物理的装置)を用い、左側のモニターが 1280x1024 であり、右側のモニターが 1024x768 で、モニターの上端を揃えている場合を考える。パネルを小さい方のディスプレイの下端で幅一杯に、高さ 50 ピクセルで表示したい場合、bottom (の柱)には 306、bottom_start_x には 1280、そして bottom_end_x には 2303 を指定するべきである(訳註：下の図(まだない)を参照)。柱の座標は画面の端からの相対座標であり、Xinerama モニターの端からのものではないことに注意。

玄論：単純な「覆ってはいけない」("do not cover")のヒントでは、例えば自動で隠れるパネルへ対応するのに、十分ではない。

補足：自動で隠れるパネルは、柱の幅(strut)として最小の値、即ち隠れた状態の大きさを指定するものとする。画面の角に存在し画面の端一杯に広がらないパネルは、矩形の位置(strut：訳註：left、right、top、bottom)を１つだけ設定するものとする。

_NET_WM_ICON_GEOMETRY, x, y, width, height, CARDINAL[4]/32

この設定してもしなくてよい(optional)プロパティは、タスクバーやアイコンボックスのような独立して機能するツールによって設定される可能性がある。同プロパティは、将来ウィンドウがアイコン化された時に表示されるはずのアイコンのジオメトリを表す。

玄論：ウィンドウ・マネージャは、このプロパティのおかげでウィンドウをアイコンへと変身させる類の素晴らしいアニメーションを表示できるようになる。

_NET_WM_ICON CARDINAL[][2+n]/32

これは、クライアントのアイコン(候補)の配列である。この仕様書では、こうしたアイコンの大きさがどのくらいであるべきかは定めていない。けれども、個々のデスクトップ環境やツールキットはそうしたことを定めている可能性がある。ウィンドウ・マネージャは、この配列中のアイコンはどれでも適切な大きさに拡大縮小することができる。

これは、ARGB を 32 ビットに詰め込んで基数としたものの配列である。32 ビットの中の上位のバイトが A、下位のバイトが B である。最初の２つの基数(整数)が(アイコンの)幅と高さである。１つの画像データを構成するピクセル群が左から右、上から下の順に１列に並んでいる。(訳註：n は画像のピクセル数？)

_NET_WM_PID CARDINAL/32

このプロパティを設定するのであれば、このウィンドウを所有しているクライアントのプロセス ID を入れなければならない。ウィンドウ・マネージャは、_NET_WM_PING プロトコルのメッセージに応答しないウィンドウを強制終了させるために、このプロパティを使用することができる。

_NET_WM_PID を設定する場合、ICCCM で規定されているプロパティ WM_CLIENT_MACHINE も設定しなければならない。ICCCM においては WM_CLIENT_MACHINE に「クライアントを実行しているマシン(X サーバを実行しているマシンの視点からそのように見えるもの)の名前を表す文字列」を設定することしか要求していないが、この仕様書に則るには、WM_CLIENT_MACHINE にクライアントのホストの完全修飾ドメイン名を設定する必要がある。

実装のための覚え書の中の「反応しないプロセスの強制終了」の項も参照。

_NET_WM_HANDLED_ICONS

ページャは、ウィンドウ・マネージャがアイコン化されたウィンドウに対してアイコンを与える必要のないことを示すために、このプロパティを自身の最上位ウィンドウの中の１つに設定することができる。例えば、タスクバーの場合、アイコン化されたウィンドウに対して(アイコンではなく)ボタンを割り当てる。

_NET_WM_USER_TIME CARDINAL/32

このプロパティには、このウィンドウでユーザの最後の活動が行われた時刻(X サーバ時間)が入る。

クライアントは、新たな最上位ウィンドウ全てにこのプロパティを設定するものとする。この設定はウィンドウがマップされる前に行うものとし、同ウィンドウが出現する切っ掛けとなったユーザのやり取りのタイムスタンプを設定するものとする。核となるイベントしか扱わないクライアントは、例えば、最後の KeyPress イベントあるいは最後の ButtonPress イベントのタイムスタンプを用いるであろう。一般的には、ButtonRelease イベントと KeyRelease イベントはユーザの「やり取り」とは見做さないようにするべきである。なぜかというと、アプリケーションは KeyRelease イベントをグローバル・キーバインド(global keybindings)から受け取る可能性があり、また、キーを離すイベントのタイムスタンプは、対応する押下イベントによって実行された処理よりも後の時刻を指していることがあるからである。クライアントは、アプリケーションの起動が立ち上げの通知を伴って行われた場合、最初のウィンドウが表示された時刻(タイムスタンプ)を環境変数 DESKTOP_STARTUP_ID から取得することができる。クライアントは、(例えばウィンドウが起動された時に立ち上げの通知を伴わなかった等の理由で)最初のウィンドウの表示の切っ掛けとなったユーザの「やり取り」の時刻(タイムスタンプ)を知らない場合、このプロパティを同ウィンドウに設定しないものとする。新たにマップされたウィンドウに特別な値であるゼロを設定すると、同ウィンドウがマップされた時に初めはフォーカスを当てないよう要求することができる。

クライアントは、アクティブなウィンドウを持っている場合、ユーザの活動があった時はいつでも同ウィンドウにあるこのプロパティを更新するものとする。

玄論：このプロパティのおかげでウィンドウ・マネージャは次のことができるようになる。即ち、ウィンドウがマップされた時、この新たなウィンドウがユーザの行動によって作られたものなのか、それともタイマーやその他のイベントによって活性化されたポップアップ・ウィンドウなのかに応じて、同ウィンドウのフォーカス、重ね順、位置を切り替えることができるようになる。

_NET_WM_USER_TIME_WINDOW WINDOW/32

このプロパティには、クライアントが _NET_WM_USER_TIME プロパティを設定したウィンドウの XID が入る。クライアントは、ウィンドウ・マネージャが _NET_WM_USER_TIME_WINDOW に対応しているか調べるべきであり、対応していなかった場合には通常通り最上位ウィンドウへ _NET_WM_USER_TIME プロパティを設定するものとする。

玄論：_NET_WM_USER_TIME プロパティは頻繁に変更されるので、これを最上位ウィンドウ自身に保有させると、同ウィンドウの何らかのプロパティに関心のあるアプリケーションは全て、あらゆる打鍵の度に起床させられることになってしまう(訳註：PropertyNotifyによって)。これは、バッテリーの力で動くラップトップには特に有害である。

_NET_FRAME_EXTENTS, left, right, top, bottom, CARDINAL[4]/32

ウィンドウ・マネージャは、ウィンドウのフレームの幅を _NET_FRAME_EXTENTS に設定しなければならない。left、right、top 及び bottom は、ウィンドウ・マネージャが付け加える縁それぞれの幅を表す。

_NET_WM_OPAQUE_REGION, x, y, width, height, CARDINAL[][4]/32

クライアントは、このプロパティに４つの値の組 [x, y, width, height] の配列を設定することができる。各組はウィンドウの座標系にある長方形を表しており、この長方形の中ではウィンドウの内容を構成するピクセルは完全に不透明なアルファ値を持つ。コンポジタがウィンドウを描画する際に透かし(透明性)を一切加えない場合、上記のような長方形はその後ろに描画されるもの全てを覆い隠すことになる。ARGB のヴィジュアル(X11)ではなく RGB のヴィジュアルを持つウィンドウの場合、このプロパティは通常役に立たない。ウィンドウの中の実際に不透明な領域は、shape 拡張機能を通じて設定されたウィンドウの境界領域(bounding region)と正確に一致するからである。ARGB ヴィジュアルと shape 拡張機能を通じて設定された境界領域(bounding region)とを持つウィンドウの場合、実際に不透明な領域は、このプロパティによって設定された領域とshape 拡張機能を通じて設定された境界領域とが重なる部分である。コンポジット・マネージャはこのヒントを無視してもよい。

玄論：これによって、コンポジット・マネージャは一層の最適化の余地を得る。例えば、コンポジット・マネージャは、ウィンドウの後ろの隠れた部分を描画しないようにすることができる。

_NET_WM_BYPASS_COMPOSITOR, CARDINAL/32

クライアントは、合成されずに(uncomposited)(即ちオフスクリーンのバッファに転送されずに)運用されることがウィンドウの利益になることをコンポジタに教えるため、あるいは合成されないとウィンドウが損害を受けるかもしれないことを教えるため、このプロパティを設定することができる。値 0 は、特に好みが無いことを示す。値 1 は、コンポジタにこのウィンドウの合成を無効にすべきことを伝える。値 2 は、コンポジタにこのウィンドウの合成を無効にしないようにすべきことを伝える。他の値は全て予約されているので、値 0 と同じものと見做すべきである。コンポジット・マネージャは、合成回避(bypassing compositing)の要求があった場合、フルスクリーンのウィンドウとフルスクリーンでないウィンドウの両方で合成を控える(bypass)ことが可能である。けれども、合成回避の結果、合成した場合の外観と違いが生じるのであれば、コンポジット・マネージャは合成回避をしてはならない。

玄論：フルスクリーンのゲームのような一部のアプリケーションは、オフスクリーンのバッファに転送されることによる負荷(overhead)無しに、効率よく実行されることを望むであろう。ポップアップ・ウィンドウを作成するアプリケーションは、前面への表示を避けるため、合成有りで実行されることを常に望むであろう。

このプロトコルによって、ウィンドウ・マネージャはクライアントが依然として X イベントを処理しているのか否かを判断することができる。ウィンドウ・マネージャは次のことを判断するのにこのプロトコルを使うことができる。即ち、WM_DELETE_WINDOW を送られたウィンドウが閉じる(終了する)のに失敗した場合、同ウィンドウが応答するのを止めてしまったのか、それともユーザの確認を待つ等、他の理由によって一時的に止まっているだけなのかを判断するのにこのプロトコルを使うことができる。クライアントは、クライアント・ウィンドウの WM_PROTOCOLS プロパティに _NET_WM_PING を含めることによって、このプロトコルに参加する気があることを示すものとする。

ウィンドウ・マネージャは、下記のクライアント・メッセージを送信することで、いつでもこのプロトコルを使用することができる。

type = ClientMessage
window = クライアント・ウィンドウ
message_type = WM_PROTOCOLS
format = 32
data.l[0] = _NET_WM_PING
data.l[1] = タイムスタンプ
data.l[2] = クライアント・ウィンドウ
残りの data.l[] = 0

プロトコルに参加しているクライアントは、このメッセージを受け取った場合、即座にルート・ウィンドウに同メッセージを送り返さなければならない。その際には、同メッセージ中の「window」がルート・ウィンドウを指すように書き換え、この仕様書の他の全てのルート・ウィンドウ宛てメッセージと同じイベント・マスクを設定した XSendEvent を呼び出さなければならない。クライアントは、このメッセージで受け取ったイベントの中の「window」以外のフィールドを変更してはならない。これには配列 data.l[5] の５つの値も含まれる。ウィンドウ・マネージャは、必要であれば、イベント中のタイムスタンプと data.l[2] フィールドを使って PING を一意に特定することができる。一部の古いクライアントは data.l[2] から data.l[4] までを保存しないことがあるので注意。

ウィンドウ・マネージャは、クライアントが妥当な時間内にこのプロトコルに応答できなかった場合、同クライアントを強制終了させることができる(_NET_WM_PID を使う)。

実装のための覚え書の「反応しないプロセスの強制終了」の項も見よ。

このプロトコルは、クライアントとウィンドウ・マネージャがウィンドウ・マネージャ・フレームとクライアント・ウィンドウの再描画を同期させられるようにするものであり、XSync 拡張機能(プロトコルの仕様書 と ライブラリの説明書 を参照)を使用する。クライントは、クライアント・ウィンドウの WM_PROTOCOLS プロパティに _NET_WM_SYNC_REQUEST アトムを入れ、且つ XSync カウンタの XID を _NET_WM_SYNC_REQUEST_COUNTER プロパティに格納することで、このプロトコルに参加する気があることを示す。このカウンタの初期値は、この仕様書では定めない。

ウィンドウ・マネージャは、クライアントへ送られる ConfigureNotify イベントより先に、下記のクライアント・メッセージによって、このプロトコルを使用する。

type = ClientMessage
window = クライアント・ウィンドウ
message_type = WM_PROTOCOLS
format = 32
data.l[0] = _NET_WM_SYNC_REQUEST
data.l[1] = タイムスタンプ
data.l[2] = 更新リクエスト番号(update request number)の下位 32 ビット
data.l[3] = 更新リクエスト番号(update request number)の上位 32 ビット
残りの data.l[] = 0

１つ以上の上記メッセージと ConfigureNotify の組み(pair)を受信し、且つその ConfigureNotify に関連する全ての再描画を処理し終えたら、クライアントは、最後に受信したクライアント・メッセージの data.l[2] 及び data.l[3] フィールドで表される 64 ビットの数値を _NET_WM_SYNC_REQUEST_COUNTER に設定しなければならない。

ウィンドウ・マネージャは、XSync 拡張機能の Alarm もしくは Await のどちらかの機構を用いることで、クライアントが ConfigureNotify イベントの処理を終えたのが何時なのか知ることができる。ウィンドウ・マネージャは、クライアントが追いつけないほどの速さでウィンドウのサイズを変更しないようにするべきである。

クライアント・メッセージの中の更新リクエスト番号(update request number)はウィンドウ・マネージャが決定するのであるが、ウィンドウ・マネージャはこれを 0 に設定してはいけない。この番号は基本的に、各メッセージが送られる度に 1 づつ増やしていくものである。XSync カウンタの初期値をこの仕様書では定めていないので、ウィンドウ・マネージャは、いつでも XSync カウンタの値を設定することが可能であり、また新たなウィンドウを管理し始める時には必ず XSync カウンタの値を設定しなければならない。

_NET_WM_FULLSCREEN_MONITORS, CARDINAL[4]/32

フルスクリーン状態が有効になった時のウィンドウの上、下、左、右の端を表す、４つのモニターの番号(訳註：要確認)の入った読み込み専用の配列である。この番号は、Xinerama 拡張機能が返すモニターの集合から得られるものである。

あるウィンドウのために一時的に存在するウィンドウであって _NET_WM_FULLSCREEN_MONITORS が設定されているもの(例えば _NEW_WM_WINDOW_TYPE_DIALOG 型のウィンドウ)は通常、モニターの中の１つだけを基準として配置される(例えば、その中央に)。このモニターは、マウス・ポインタを持つものであったり、フルスクリーン状態でないウィンドウを持つものであったりする。

この配列の中身を変更したいクライアントは、ルート・ウィンドウへ _NET_WM_FULLSCREEN_MONITORS 型のクライアント・メッセージを送信しなければならない。ウィンドウ・マネージャは、ウィンドウの現在の状態を反映するように、この配列を最新状態に保ちつづけなければならない。

  window  = クライアント・ウィンドウ
  message_type = _NET_WM_FULLSCREEN_MONITORS
  format = 32
  data.l[0] = あるモニターの上端がフルスクリーン・ウィンドウの上端となる場合のそのモニター。
  data.l[1] = あるモニターの下端がフルスクリーン・ウィンドウの下端となる場合のそのモニター。
  data.l[2] = あるモニターの左端がフルスクリーン・ウィンドウの左端となる場合のそのモニター。
  data.l[3] = あるモニターの右端がフルスクリーン・ウィンドウの右端となる場合のそのモニター。
  data.l[4] = source indication(送信元の種別)

source indication については「リクエストの送信元の種別のヒント」の項を参照。

仮想マシン・ソフトウェアは、複数のモニターを管理する仮想オペレーティング・システムのインスタンスを運用するために、このヒントを使うことができる。ゲストの仮想マシンがこうしたモニター群を操作して適切な外観を生み出すので、アプリケーション・ウィンドウは複数のモニターに跨ることができる。

このヒントは動画再生やプレゼン用のアプリケーションでも使用され、ユーザが複数のモニターに跨った映像を表示することを可能にする。

どちらの場合もアプリケーションは、自分がフルスクリーン表示になる際にどのモニターへ広がっていくのかをユーザが設定できるように、何らかのユーザ・インタフェイスを備えるであろう。ウィンドウ・マネージャは、可能であったとしても、そのようなインタフェイスを提供する必要はない。

モニターの設定に変更があった場合、アプリケーションには、自分をどのモニターに表示したいのか再計算する責務がある。ウィンドウ・マネージャは、前と同じモニター番号を使い続けてもよいし、リスト(the list、訳註：要確認：_NET_WM_FULLSCREEN_MONITORS の配列？)を消去して「通常の」フルスクリーン状態に戻してもよい。

ウィンドウ・マネージャは、このヒントを _NET_SUPPORTED に含めることで、自分が対応しているウィンドウの型(type)全てに対して合理的な配置を行うこと(例えば主たるウィンドウの真ん中にダイアログを配置することや、その他ウィンドウ・マネージャが合理的だと考える操作は何でも)を宣言することができる。これは同時に次のことも意味している。即ち、クライアントは、このヒントが有効になっていることを知った場合、特定の位置取りを要求するために PPosition ヒント及び USPosition ヒントを濫用しないか、あるいは使用すらしないものとする。特に次の２点に注意する。

玄論：多くの場合、ウィンドウ・マネージャの方がアプリケーションよりも上手くウィンドウの位置取り(これは調整可能であることもある)を決めることができる。しかしながら、この仕様を書いている時点では、ウィンドウ・マネージャにとってそうしたフラグを使用すべき時を見極めるのは難しいことである。なぜかというと、多くのアプリケーションは位置取りのフラグを濫用したり、無駄にデフォルトの位置を指定したりするからである。

補足：このプロパティは、_NET_SUPPORTED の配列の中に並べられる他は、使用される場面が一切無い。

コンポジット・マネージャは、管理しているスクリーンのそれぞれに対して１つづつ、_NET_WM_CM_Sn という名前のセレクションの所有権を獲得しなければならない。ここでの「n」はスクリーンの番号を表す。コンポジット・マネージャは、ICCCM の 2.8 節にある「マネージャ・セレクション」の規約に従わなければならない。

WM_TRANSIENT_FOR プロパティは、ウィンドウ・マネージャによって管理されているウィンドウに設定するものであると ICCCM に書いてある。しかし、この仕様書では同プロパティの使用対象を override-redirect ウィンドウにまで拡大する。override-redirect ウィンドウが別のウィンドウのためのポップアップである場合、クライアントは、この override-redirect ウィンドウに WM_TRANSIENT_FOR プロパティを設置し、同プロパティに上述の別のウィンドウの ID を設定するものとする。

例えば、クライアントは、ドロップダウン・メニューに WM_TRANSIENT_FOR プロパティを設置し、同プロパティにこのメニューバーを所有する最上位のアプリケーション・ウィンドウの ID を設定するものとする。

この仕様は、完全に独立したデスクトップであって、画面領域よりも大きかったりそうでなかったりするものが１つ以上集まることによって構成されるデスクトップ・モデルを想定している。デスクトップが画面より大きい場合にスクロール機能やページング(paging)機能を提供するかどうか(実装しているかどうか)は、ウィンドウ・マネージャ次第である。

この仕様では、デスクトップと同じ大きさであって _NET_WM_WINDOW_TYPE_DESKTOP を持つウィンドウ(shape無し)をデスクトップ全て(all desktops)にマップする方法で、ファイル・マネージャであるデスクトップを実装するよう提案する。これによってデスクトップはフォーカス可能となり、ファイル・マネージャ機能の実装もとても簡単になる。またこの方法は、shape 機能を使った小さなウィンドウを多数管理するよりも高速である。ファイル・マネージャはこのウィンドウの背景を描画する。ウィンドウを操作するためのハンドル(訳註：ウィンドウ ID か何か)の入ったルート・ウィンドウのプロパティが存在するべきであり、背景を描画したいアプリケーション(xearth 等)はこれを使う。

WM_TRANSIENT_FOR プロパティに None もしくはルート・ウィンドウが設定してある場合、そのウィンドウは同じグループに属する他の全てのウィンドウに対して「一時的」(transient)であるものとして扱うべきである。これは ICCCM の規約に少し違反していると言われてきた。が、このような動作は多くのツールキットやウィンドウ・マネージャでほぼ標準となっており、何かを壊す可能性は極めて低いので、これを標準として本文書に規定することは理に適っていると思われる。

ユーザの即時の行動を待ち望むウィンドウは、ICCCM に書かれている通り、WM_HINTS.flags の UrgencyHint のビットを使ってその希望を表明するものとする。

各ウィンドウは、ICCCM の WM_NORMAL_HINTS プロパティにおいて「minheight = maxheight」且つ「minwidth = maxwidth」と設定することで、自身がサイズ変更不可であることを示すことができる。ウィンドウ・マネージャは、そのようなウィンドウを他のものとは違ったやり方で装飾することができる。

この仕様書は、ウィンドウ・マネージャから独立したページャとタスクバーにもそれなりに対応しようと試みている。この仕様書で述べられた機構を用いて為し得ること以上のことを為すような追加機能を必要とする、あるいは要望するウィンドウ・マネージャは、ウィンドウ・マネージャ用のヒントやその他の手段を追加で用いてウィンドウ・マネージャと通信する、独自のページャを実装することができる。

ページャは、以下の指針に従ってウィンドウの縮小表現を表示するか否かを決定するものとする。

ウィンドウ・マネージャの実装者は、MapRequest イベントと ConfigureRequest イベントを扱う方法の決定的な仕様として、ICCCM を参照するべきである。しかしながら、ICCCM のこの分野の記述は誤解しやすいので、本文書に以下の説明を載せておく。

(訳註：Multiple Document Interface)

次のことはこの仕様書の著者が認めるところである。即ち、ウィンドウ・マネージャが Window-in-Window MDI 型のアプリケーションの一部であるウィンドウを管理できるようにするための標準的な手法は存在しない。アプリケーションの作者は、MDI の他の形式を用いるか、さもなければこの仕様書の将来の改訂で採用されるべき仕組みを提案するべきである。

プロセスが _NET_WM_PING プロトコル・メッセージに応答できなかった場合、プロセスの強制終了を試みるために _NET_WM_PID を使用することができる(ICCCM で規定されている WM_CLIENT_MACHINE と組み合わせて)。

WM_CLIENT_MACHINE は通常、XSetWMProperties() を呼び出して設定する。現在のホストを指すホスト名は gethostname() で取り出すことができる。gethostname() が使えない環境では、実装者は uname() で返る utsname 構造体の nodename フィールドの値を使用することができる。WM_CLIENT_MACHINE の値がホストの完全修飾ドメイン名である保証は無いことにも注意。ホスト名を取り出す方法の例を載せる。

int net_get_hostname (char *buf, size_t maxlen)
{
#ifdef HAVE_GETHOSTNAME
	if (buf == NULL) return 0;

	gethostname (buf, maxlen);
	buf [maxlen - 1] = '\0';

	return strlen(buf);
#else
	struct utsname name;
	size_t len;

	if (buf == NULL) return 0;

	uname (&name);
	len = strlen (name.nodename);

	if (len >= maxlen) len = maxlen - 1;
	strncpy (buf, name.nodename, len);
	buf[len] = '\0';

	return len;
#endif
}

異なるデスクトップ環境相互間での情報利用可能性を高めるために、多層化された重ね順の各層は、以下の順序で背面から重ねていくのが望ましい。

自分以外のウィンドウのために一時的に存在する(transient)ウィンドウは、そのウィンドウの前面に表示し続けるものとする。

ウィンドウ・マネージャは、一部のウィンドウの重ね順の位置を上記のものとは別の位置にすることもできる。これによって、例えば、ユーザがアクティブ・ウィンドウを一時的に最前面に持ってきて、同ウィンドウがフォーカスを失った時に後ろへ戻すという動作をすることを認めることができる。

クライアントからのリクエストには、クライアントの型を含んでいるものがある。例えば _NET_ACTIVE_WINDOW である。今のところ、この型は、普通のアプリケーションなら 1、そしてページャやユーザの直接の行動を伝えるその他のクライアントなら 2 である(ウィンドウ・マネージャは、アプリケーションからのリクエストをユーザの直接の行動から生じたリクエストとは違う形で処理することにしてもよい)。この仕様の古い版にしか対応してないクライアントは、「source indication」の値に 0 を入れてしまうので、送信元たる自身の種別を全く明かさないことになる。これによって、そのメッセージの中の一部のフィールドが古い版の仕様にしか則っていない、ということがわかる可能性もある。