入り口に戻る

原文はこちら。

翻訳に使ったレイアウト(1頁に纏まっているもの)はこちら。

翻訳にあたって、オープンソースグループ・ジャパンの MIT ライセンスの訳、及び AzSky2 の「X Window System (X11) プログラミング」の記事を参考にした。

## Extended Window Manager Hints(日本語訳)

### X Desktop Group

1.5

2011 年 11 月 29 日

## はじめに

### バージョン

この文書は 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 に無い機能

ウィンドウ・マネジメントの機能や動作の中には、ICCCM では定めがないけれども現代のウィンドウ・マネージャとデスクトップ環境を使っていると普通に見かけるものが多数存在する。

### ウィンドウの状態の追加

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

#### 最大化(Maximization)

最大化は、古くからあるウィンドウ・マネージャの機能である。ICCCM の初期の草案にすら ZoomedState(拡大化状態) が存在した。ウィンドウを最大化するには、当該ウィンドウに対してできる限り広いスクリーン領域を与えるものとする(スクリーン領域全体ではなく、それより狭い「作業領域」(workarea)である可能性がある。なぜかというと、ウィンドウ・マネージャは他のウィンドウ群のためにいくらかの領域を残すことができるから)。ウィンドウ・マネージャは、最大化するウィンドウのジオメトリを覚えておき、最大化を解除する際に同ジオメトリの通りにウィンドウを復元することが望ましい。現代のウィンドウ・マネージャは大抵、水平の最大化と垂直の最大化を分けて実行することができる。

X11 R6.4 における Xinerama の拡張の導入によって、「最大化」はより複雑なものになった。Xinerama によって、スクリーンは自由にジオメトリを構成して複数のモニターに跨ることができるようになった。そのような環境では、ウィンドウの最大化とは、スクリーン全体を覆うようにウィンドウを拡大することではなく、同ウィンドウが表示されているモニター全体を覆うように拡大することを意味する。もちろん、モニターの境界を跨いでいるウィンドウのような、どちらとも言えない例も存在し、スクリーン全体への「本物の」最大化も時として有効である。

#### 巻き上げ(Shading)

一部のデスクトップ環境では、アイコン化に代わるものとして「巻き上げ」(shading あるいは rollup)という機能を用意している。巻き上げられたウィンドウは大抵タイトルバーしか表示されなくなり、クライアント・ウィンドウは隠れてしまう。したがって、巻き上げはタイトルバーで飾られていないウィンドウの役には立たない。

### モーダリティ(Modality)

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

### 大きなデスクトップ(Large Desktops)

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

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

#### 実装のための覚え書

大きなデスクトップを実装する方法は２つある。１つは、管理対象のウィンドウ(親変更をする場合はそのフレーム)をルート・ウィンドウの子のままにしておく方法である。ビューポートの移動は、全ての管理対象ウィンドウを逆方向に移動させることで実現する。

もう１つの方法は、全ての管理対象ウィンドウの親をそのためだけに作られた大きなウィンドウ(やや不適当な名前だが「仮想ルート」(virtual root)という)へと変更する方法である。ビューポートの移動は、仮想ルートを逆方向へ移動させることで実現する。

どちらの方法も完全に ICCCM を守っているけれども、後のものは、以下のクライアントにとっては少し問題を起こす可能性があるものである。即ち、ウィンドウ・マネージャが(クライアントの)最上位ウィンドウに施した装飾を調べようとするクライアントと、ルート・ウィンドウに背景画像を描こうとするクライアントである。

### 固定ウィンドウ(Sticky windows)

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

### 仮想デスクトップ(Virtual Desktops)

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

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

#### 実装のための覚え書

仮想デスクトップを実装する方法は、少なくとも２つある。１つは、複数の仮想ルート(大きなデスクトップの「実装のための覚え書」を見よ)を使い、仮想ルートの重ね順を操作することによって「現在のデスクトップ」を変更する方法である。これは完全に ICCCM に則っているが、大きなデスクトップの箇所の「実装のための覚え書」で述べた問題がある。

２つ目の方法は、管理対象のウィンドウ全てをルート・ウィンドウの子として留めておいて、「現在のデスクトップ」上に無いウィンドウ群のフレームをアンマップする方法である。ICCCM では、アンマップされたウィンドウは IconicState (アイコン化状態)になるものとされている。本当にアイコン化されたり最小化されたりしたウィンドウは、_NET_WM_STATE_HIDDEN プロパティを設定するものとし、これによって同ウィンドウが「画面上に存在するもの」として扱われないよう、ページャ(pager)に知らせるものとする。

### ページャ(Pagers)

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

### タスクバー(Taskbars)

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

### 活性化(Activation)

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

### 動きのあるアイコン化(Animated iconification)

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

### Window-in-window MDI

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

### Override-redirect ウィンドウ

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

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

### 重ね順の多層化(Layered stacking order)

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

### この仕様書の射程

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

- クライアントが自身の初期状態(最大化、巻き上げ(shading)、位置の固定(stickiness)、所属するデスクトップ、及び重ね順に関するもの)について影響を与えられるようにすること。

- クライアントがウィンドウ・マネージャに対して自身のウィンドウの型(type)を教えられるようにすることによって、ウィンドウの装飾を変更したり特定の重ね順を維持したりするウィンドウ・マネージャの能力を向上させること。

- override-redirect 属性のウィンドウに装飾と演出効果(effect訳註：要確認)を加えるコンポジット・マネージャの能力を向上させること。

- ページャとタスクバーを別個のクライアントとして実装できるようにした上で、規約に忠実なウィンドウ・マネージャならどれとでも協働できるようにすること。

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

- ICE or Corba のような別の IPC 機構(Inter Process Communication mechanisms)。

- ウィンドウ・マネージャの構成。

- ウィンドウ・マネージャの情報の文書化。

- デスクトップの直接の子であるクライアント。(訳註：Clients appearing on a proper subset of desktops.「a proper subset」は、数学の「真部分集合」ではない。ここでいう「subset」は子要素の集合を指す。a proper subset は、中間要素を挟まない直接の子要素の集合の意。)

- ウィンドウの中にウィンドウを持つ MDI(Multiple Document Interface)。

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

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

## ルート・ウィンドウに設定するプロパティ(と関連メッセージ)

この仕様書においては、「ルート・ウィンドウにメッセージを送る」という言葉は常に次のような意味で理解するものとする。即ち、クライアントは規定された内容を持つ ClientMessage イベントを作成し、同イベントを以下に挙げる引数を持つ SendEvent リクエストによって送信する、という意味である。

    destination     ルート
    propagate       False
    event-mask      (SubstructureNotify|SubstructureRedirect)
    event           規定されている ClientMessage

### _NET_SUPPORTED

    _NET_SUPPORTED, ATOM[]/32

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

### _NET_CLIENT_LIST

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

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

### _NET_NUMBER_OF_DESKTOPS

    _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

    _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

    _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

    _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

    _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

    _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

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

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

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

### _NET_SUPPORTING_WM_CHECK

    _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

    _NET_VIRTUAL_ROOTS, WINDOW[]/32

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

### _NET_DESKTOP_LAYOUT

    _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_S`n` であり、`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

    _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 型のクライアント・メッセージ・リクエストをルート・ウィンドウへ送信しなければならない。

    _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

    _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

    _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 メッセージを送信したクライアントとボタンを離したユーザとの間には競合状態(race condition)が存在するので、ウィンドウ・マネージャは、上記操作を終了する何か別の手段も用意しておくことが望ましい(ESC キーを押すなど)。クライアントは、ボタンから手が離れたのを自分で検知した場合に、_NET_WM_MOVERESIZE_CANCEL という特別な値を用いたメッセージを送信することで、上記の操作を取り消すことができる(クライアントは、移動・サイズ変更のメッセージを送信した後にボタン押下解除を知った場合、この取り消しメッセージを送信するべきである。これは、ウィンドウ・マネージャの占有取得がボタン押下解除に間に合わなかったことを示す)。

### _NET_RESTACK_WINDOW

    _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

    _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

    _NET_WM_NAME, UTF8_STRING

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

### _NET_WM_VISIBLE_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

    _NET_WM_ICON_NAME, UTF8_STRING

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

### _NET_WM_VISIBLE_ICON_NAME

    _NET_WM_VISIBLE_ICON_NAME, UTF8_STRING

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

### _NET_WM_DESKTOP

    _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

    _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

          _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

    _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

    _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

    _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

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

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

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

### _NET_WM_ICON

    _NET_WM_ICON CARDINAL[][2+n]/32

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

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

### _NET_WM_PID

    _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_HANDLED_ICONS

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

### _NET_WM_USER_TIME

    _NET_WM_USER_TIME CARDINAL/32

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

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

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

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

### _NET_WM_USER_TIME_WINDOW

    _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

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

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

### _NET_WM_OPAQUE_REGION

    _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

    _NET_WM_BYPASS_COMPOSITOR, CARDINAL/32

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

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

## ウィンドウ・マネージャのプロトコル

### _NET_WM_PING

このプロトコルによって、ウィンドウ・マネージャはクライアントが依然として 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 を使う)。

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

### _NET_WM_SYNC_REQUEST

このプロトコルは、クライアントとウィンドウ・マネージャがウィンドウ・マネージャ・フレームとクライアント・ウィンドウの再描画を同期させられるようにするものであり、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

    _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_WM_FULL_PLACEMENT

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

- USPosition は、位置をユーザが指定したことを示す目的にのみ使用し、その他のことには使用してはならない(詳しくは ICCCM の 4.1.2.3 の節を参照)。

- PPosition は、特殊な位置を使用すべき場合に限って、位置を指定するために使用するものとする。ダイアログ・ウィンドウを主たるウィンドウの真ん中に配置するといったように、「デフォルト」の位置取りを指定しないようにするべきである。

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

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

## コンポジット・マネージャ(Compositing Managers)

コンポジット・マネージャは X クライアントであり、全てのウィンドウをオフスクリーンのピクスマップへ転送するコンポジット拡張と、そうしたオフスクリーンのピクスマップで描画が行われた時にそれを検知するダメージ拡張(Damage extension)とを使用するものである。スクリーン上に上記のピクスマップを描画するのはコンポジット・マネージャの仕事であり、その際には半透明効果や変形効果を付加することもある。

この節では、コンポジット・マネージャとアプリケーションとのやり取りについて述べる。

### マネージャ・セレクション「_NET_WM_CM_S`n`」

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

### override-redirect ウィンドウに WM_TRANSIENT_FOR を設定

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

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

## 実装のための覚え書

### Desktop/workspace model

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

### ファイル・マネージャであるデスクトップ(File Manager desktop)

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

### 一時的なウィンドウのための高度な支援機能の実装

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

### 緊急フラグ(Urgency)

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

### 固定サイズのウィンドウ

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

### ページャとタスクバー(Pagers and Taskbars)

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

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

- ウィンドウに _NET_WM_STATE_SKIP_PAGER もしくは _NET_WM_STATE_HIDDEN が設定されている場合、ページャはそのウィンドウを表示しないようにするべきである。

- ページャは、ある種の型を持つウィンドウを表示しないことにしてもよい。例えば、この仕様書では推奨していないが、_NET_WM_WINDOW_TYPE_DOCK 型のウィンドウの表示を避けるのが普通である。

- ウィンドウに _NET_WM_STATE_SKIP_PAGER ヒントと _NET_WM_STATE_HIDDEN ヒントが存在せず、ウィンドウ・マネージャが _NET_WM_STATE_HIDDEN に対応していることを表明している場合、同ウィンドウが NormalState もしくは IconicState であれば、同ウィンドウを表示するものとする。

- ウィンドウ・マネージャが _NET_WM_STATE_HIDDEN に対応していない場合、ページャは IconicState のウィンドウを表示しないものとする。そうしたウィンドウ・マネージャは、おそらくこの仕様書の古い版に依拠している。

### ウィンドウのジオメトリ

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

- ウィンドウ・マネージャは、MapRequest イベントと ConfigureRequest イベントの両方の WM_NORMAL_HINTS の win_gravity フィールドをそのまま受け入れなければならない。(ICCCM バージョン 2.0、§4.1.2.3 及び §4.1.5)

- 代用の ConfigureNotify イベントを生成する場合、クライアント・ウィンドウの左上隅の座標を指定しなければならず、この座標はルート・ウィンドウの(座標空間の)原点を基準としたものでなければならない(言い換えると、win_gravity は無視するということである)。(ICCCM バージョン 2.0、§4.2.3)

- ウィンドウ・マネージャは、各クライアント・ウィンドウの参照点(reference point基準点)を保持し、以下に示すように、ウィンドウの win_gravity に従ってこの参照点を基準としてウィンドウを配置する。

  win_gravity: | 参照点に当たる場所
  StaticGravity | クライアント・ウィンドウの左上隅
  NorthWestGravity | フレーム・ウィンドウの左上隅
  NorthGravity | フレーム・ウィンドウの上辺の真ん中
  NorthEastGravity | フレーム・ウィンドウの右上隅
  EastGravity | フレーム・ウィンドウの右辺の真ん中
  SouthEastGravity | フレーム・ウィンドウの右下隅
  SouthGravity | フレーム・ウィンドウの下辺の真ん中
  SouthWestGravity | フレーム・ウィンドウの左下隅
  WestGravity | フレーム・ウィンドウの左辺の真ん中
  CenterGravity | フレーム・ウィンドウの中心

- アプリケーションは、いつでも自身の win_gravity の設定を自由に変更することができる。

  アプリケーションが自身の win_gravity を変更した場合、ウィンドウ・マネージャは、変更の結果としてクライアント・ウィンドウが移動しないように、参照点の位置を調整するものとする。例えば、元々アプリケーションの win_gravity が NorthWestGravity であり参照点の位置がフレーム・ウィンドウの左上隅であった場合、win_gravity が SouthEastGravity に変更された時は、参照点がフレームの右下隅を指すように調整するものとする。

  ### 補足

  win_gravity を変更して１回 ConfigureRequest を送りその後 win_gravity を元に戻すという手続きは、競合状態(race condition)が発生するために、狙い通りの動作をしない可能性がある。 ウィンドウ・マネージャは、まず WM_NORMAL_HINTS に関する PropertyNotify を受け取り、次いで ConfigureRequest を受け取り、その後もう１度 WM_NORMAL_HINTS に関する PropertyNotify を受け取る。ところが、ウィンドウ・マネージャが最初の PropertyNotify を受けて WM_NORMAL_HINTS を見に行く時までに、サーバは既に第２の変更の処理を済ませてしまっているかもしれないのである。

  ウィンドウ・マネージャがこの動作に対応している場合、アプリケーションは、上の問題を避けるため、グラヴィティを指定した _NET_MOVERESIZE_WINDOW を使用するものとする。

- アプリケーションが新しい位置 (x, y) (場合によっては新しいサイズも)を要求した場合、ウィンドウ・マネージャは新しい参照点 (ref_x, ref_y) を計算する。その際には、下表に示すように、クライアント・ウィンドウの (場合によっては新しい) サイズ (width, height)、ボーダの幅 (bw) 及び win_gravity に基いて計算を行う。

  ウィンドウ・マネージャは、位置の変更の次の要求が来るまでは、この時に定めた新たな参照点を使用することになる。

  win_gravity: | ref_x: | ref_y:
  StaticGravity | x | y
  NorthWestGravity | x-bw | y-bw
  NorthGravity | x+(width/2) | y-bw
  NorthEastGravity | x+width+bw | y-bw
  EastGravity | x+width+bw | y+(height/2)
  SouthEastGravity | x+width+bw | y+height+bw
  SouthGravity | x+(width/2) | y+height+bw
  SouthWestGravity | x-bw | y+height+bw
  WestGravity | x-bw | y+(height/2)
  CenterGravity | x+(width/2) | y+(height/2)

- アプリケーションがサイズ変更だけを要求した場合、参照点は動かない。例えば、サイズ変更されたクライアント・ウィンドウの win_gravity が SouthEastGravity であった場合、同ウィンドウのフレームの右下隅は動かず、代わりに左上隅の位置がサイズ変更の分だけ移動することになる。

- ウィンドウ・マネージャは、初期配置の時の参照点を計算するには、初期ウィンドウのサイズを考慮するものとし、あたかも初期ウィンドウがこのウィンドウのフレームであるかのように扱うものとする。

### ウィンドウの中にウィンドウがある MDI (Window-in-Window MDI)

(訳註：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
    }

### 重ね順(Stacking order)

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

- _NET_WM_TYPE_DESKTOP 型のウィンドウ群

- _NET_WM_STATE_BELOW 状態を持つウィンドウ群

- 他のどの層にも属してないウィンドウ群

- _NET_WM_TYPE_DOCK 型のウィンドウ群(但し _NET_WM_TYPE_BELOW 状態を持つ場合は除く) 及び _NET_WM_STATE_ABOVE 状態を持つウィンドウ群

- _NET_WM_STATE_FULLSCREEN 状態を持ち、フォーカスを得ているウィンドウ群

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

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

### リクエストの送信元の種別のヒント(Source indication in requests)

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

## 参考文献

[UTF8]

  F. Yergeau,"UTF-8, a transformation format of ISO 10646", RFC 2279

[ICCCM]

  David Rosenthal and Stuart W. Marks, "Inter-Client Communication Conventions Manual (Version 2.0)", X Consortium Standard, X Version 11, Release 6.3

## 著作権

Copyright (C) 2000-2003 See Contributors List

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

(訳)

(Copyright (C) 2000-2003 貢献者一覧を参照)

(本ソフトウェアおよび関連する文書のファイル（以下「ソフトウェア」）の複製を取得した全ての人物に対し、以下の条件に従うことを前提に、ソフトウェアを無制限に扱うことを無償で許可する。これには、ソフトウェアの複製を使用、複製、改変、結合、公開、頒布、再許諾、および/または販売する権利、およびソフトウェアを提供する人物に同様の行為を許可する権利が含まれるが、これらに限定されない。)

(上記の著作権表示および本許諾表示を、ソフトウェアの全ての複製または実質的な部分に記載するものとする。)

(ソフトウェアは「現状有姿」で提供され、明示的であるか黙示的であるかを問わず、いかなる種類の保証も行われない。ここでいう保証には、商品性、特定目的への適合性、および権利の非侵害性に関する保証も含まれるが、これらに限定されるものではない。著作者は、契約、不法行為、またはその他の行為であるかを問わず、ソフトウェアまたはソフトウェアの使用もしくはその他に取り扱いに起因または関連して生じるいかなる請求、損害賠償、その他の責任について、一切の責任を負わない。)

## 貢献者

Sasha Vasko

Bradley T. Hughes

Dominik Vogt

Havoc Pennington

Jeff Raven

Jim Gettys

John Harper

Julian Adams

Matthias Ettrich

Micheal Rogers

Nathan Clemons

Tim Janik

Tomi Ollila

Sam Lantinga

The Rasterman

Paul Warren

Owen Taylor

Marko Macek

Greg Badros

Matthias Clasen

David Rosenthal

Lubos Lunak

Rob Adams

Thomas Fitzsimmons

Olivier Chapuis

Søren Sandmann

Grant Patterson

## 変更履歴

### 1.4 の草案からの変更点

- _NET_WM_BYPASS_COMPOSITOR を追加。

- _NET_WM_STATE_FOCUSED を追加。

- _NET_WM_OPAQUE_REGION を追加。

### 1.3 からの変更点

- _NET_WM_MOVERESIZE_CANCEL を追加。

- override-redirect ウィンドウで使う新たなウィンドウ型を追加：
  _NET_WM_WINDOW_TYPE_DROPDOWN_MENU、_NET_WM_WINDOW_TYPE_POPUP_MENU、_NET_WM_WINDOW_TYPE_TOOLTIP、_NET_WM_WINDOW_TYPE_NOTIFICATION、_NET_WM_WINDOW_TYPE_COMBO、及び _NET_WM_WINDOW_TYPE_DND である。

- コンポジット・マネージャのための新たなマネージャ・セレクション _NET_WM_CM_Sn を追加。

- 「override-redirect ウィンドウに WM_TRANSIENT_FOR を設定」の項を追加。

- _NET_WM_USER_TIME_WINDOW を追加。

- _NET_WM_FULL_PLACEMENT を追加。

- _NET_WM_FULLSCREEN_MONITORS を追加。

### 1.2 からの変更点

- 「source indication」をメッセージ _NET_CLOSE_WINDOW、_NET_WM_MOVERESIZE、_NET_MOVERESIZE_WINDOW、_NET_WM_DESKTOP 及び _NET_WM_STATE に追加。

- 不透明なサイズ変更の際、アプリケーション・ウィンドウとウィンドウ・マネージャ・フレームとの描画を同期させられるように _NET_WM_SYNC_REQUEST を追加。

- クライアントが自身のウィンドウ・フレームの幅の情報を取り出せるように _NET_REQUEST_FRAME_EXTENTS と _NET_FRAME_EXTENTS を追加。

- 新たな状態 _NET_WM_STATE_DEMANDS_ATTENTION を追加。

- _NET_ACTIVE_WINDOW メッセージに「タイムスタンプ」「source indication」「要求者のアクティブ・ウィンドウ」の３つのフィールドを追加。

- _NET_RESTACK_WINDOW メッセージを追加。

- 全幅でない長さの柱(strut矩形)が使えるように新たなプロパティ _NET_WM_STRUT_PARTIAL を追加。

- 実装のための覚え書における「ウィンドウの移動」(Window Movement)の項を書き直し、見出しを「ウィンドウのジオメトリ」(Window Geometry)に変更。

- 実装のための覚え書における「緊急フラグ」(Urgency)の項を書き直し、このヒントがダイアログだけに関わるものではないことを明確にした。

- _NET_DESKTOP_LAYOUT のフィールド「X」「Y」の仕様を修正し、わかりやすいように名前を「columns」と「rows」に変更した。

- _NET_WM_STATE_MODAL の説明を変更し、アプリケーションが「グループに対してモーダルなウィンドウ」に関する ICCCM の規則に違反しなくて済むようにした。けれども、依然として「WM_TRANSIENT_FOR=ルート」とする方言には対応している。

- クライアント・メッセージの中の(今はまだ)使われていないフィールドには 0 を指定しなければならない、と定めた。

- _NET_WM_PING メッセージにクライアント・ウィンドウの情報を入れることになった。フィールド data.l[2] を使用する。

- ウィンドウにおけるユーザの活動を検知するために _NET_WM_USER_TIME を追加。

- _NET_WM_STATE_FULLSCREEN が解除された場合にウィンドウ・マネージャが元のジオメトリを復元すべきことを明確に定めた。

### 1.1 からの変更点

- _NET_WM_PID を設定する時に WM_CLIENT_NAME(STRING)(訳註：WM_CLIENT_MACHINEの間違い)も設定するように変更した。(原文：Changed WM_CLIENT_NAME(STRING) from suggested to required for _NET_WM_PID.)(訳註：英語の意味がわからなかったので、推測で文章を作った。)

- WM_CLIENT_NAME(STRING)(訳註：WM_CLIENT_MACHINEの間違い)の中身の設定についての記述とサンプル・コードを追加した。

- _NET_WM_WINDOW_TYPE_SPLASH と _NET_WM_WINDOW_TYPE_UTILITY を追加した。

- _NET_WM_STATE_FULLSCREEN を追加。

- _NET_WM_ALLOWED_ACTIONS を追加。

- _NET_WM_STATE_HIDDEN を追加し、_NET_WM_STATE_SKIP_PAGER と _NET_WM_STATE_SKIP_TASKBAR の使い途を明確にした。IconicState 状態に関して ICCCM に準拠するように、仮想デスクトップの実装についての節を書き換えた。これには、_NET_WM_STATE_HIDDEN を使って曖昧さを無くす手法を用いた。ページャに関する実装のための覚え書を追加し、どんな場合にウィンドウを表示すべきかについて記述した。

- _NET_WM_MOVERESIZE メッセージに「button」フィールドと、キーボードからの動作のための「direction」の新しい値とを追加した。

- ウィンドウが Withdrawn 状態へ移る時(ウィンドウが引っ込められる時)に _NET_WM_STATE と _NET_WM_DESKTOP を削除すべきことを書き加えた。

- ページャがデスクトップ間のジオメトリ(デスクトップ同士の位置関係)を指定できるように、_NET_DESKTOP_LAYOUT を追加した。

- _NET_SHOWING_DESKTOP を追加した。

- _NET_WM_STATE_ABOVE と _NET_WM_STATE_BELOW を追加し、多層化された重ね順の推奨表示順序についての記述を加えた。

- _NET_MOVERESIZE_WINDOW を追加。

- 引用部分のマークアップ(HTML)を改善させた。

- _NET_DESKTOP_GEOMETRY と _NET_WM_HANDLED_ICONS の説明をより詳しくした。また、「反応しないプロセスの強制終了」の項の WM_CLIENT_MACHINE の説明を改良した。

- 貢献者の一覧に Lubos Lunak の名を加えた。

### 1.0 からの変更点

- 文書の形式(doctype)を修正(訳註：html文書にDOCTYPE宣言は無かった)。著者の情報を追加。データを更新。

- 仕様書そのものについての説明の表現をより包括的なものにし、この仕様書の「繋ぐ」性質を反映した記述にした。

- さまざまな誤植、文法上の間違い、綴りの間違いを訂正した。

- _NET_SUPPORTED にはプロパティ名を表すアトムだけでなく、全てのアトムが入ることを明確にした。

- 「MUST」(〜しなければならない)と「SHOULD」(〜するものとする)の使い方をいくつも修正した。

- _NET_WM_ICON の「基数」(cardinals)であるべき場所が「バイト」(bytes)になっていた問題を直す。

- ISO-8559-1 の文字(訳註：ISO-8859-1 の間違い)を実体(訳註：「ESC」のことか？)で置き換えた。

### 1.0pre5 からの変更点

- 「変更履歴」を末尾に移動した。

- UTF-8 の参考文献の記述を更新した。

- ウィンドウ・グラヴィティの情報の記述を更新した。

- 「著作権」の節を追加。

- 些細な誤植を修正した。

### 1.0pre4 からの変更点

- 大きなデスクトップにおける、クライアントが申告したジオメトリの解釈方法が明確になった。

- _NET_DESKTOP_NAMES の説明が詳しくなった。

- _NET_WM_ICON_NAME と _NET_WM_VISIBLE_ICON_NAME を追加。

- _NET_WM_STRUT の説明の言葉遣いの改良を試みた。

- _NET_WORKAREA を、ビューポートに対して相対的な位置を持つジオメトリの配列に変更した。

- _NET_NUMBER_OF_DESKTOPS の変更の影響を受ける(dependent)プロパティの目録を更新し、_NET_WORKAREA と _NET_DESKTOP_VIEWPORT をそこに加えた。

- 全てのクライアント・メッセージの型式表示を整えた。

### 1.0pre3 からの変更点

- ICCCM には無いが一般的である機能についての情報を追加。

- ルート・ウィンドウへのメッセージ送信についての説明を追加。

- 型の名前から接頭辞「XA_」を取り除く。

- 「mapping order」が初めてマップされた順番であることを明らかにし、両方の順番の配列中での並び方を規定した。(訳註：_NET_CLIENT_LIST と _NET_CLIENT_LIST_STACKING の話)

- デスクトップ群が _NET_DESKTOP_GEOMETRY で指定された共通サイズを持つことを明確にした。

- _NET_DESKTOP_VIEWPORT の説明を書き直した。

- _NET_CURRENT_DESKTOP の型式表示を整えた。

- 「window handle」を「window ID」で置き換えた。

- _NET_WORKAREA の型式表示を整えた。

- _NET_VIRTUAL_ROOTS の利点についての記述を書き直した。

- _NET_WM_MOVERESIZE の項にポインタの占有についての記述を追加した。

- _NET_WM_STATE の項にあった誤植を訂正した。

- _NET_WM_STATE_SKIP_PAGER を追加。

- _NET_WM_STRUT の型式表示を整えた。

- _NET_WM_ICON_GEOMETRY の型式表示を整えた。

### 1.0pre2 からの変更点

- 一貫性を考えて _NET_SET_NUMBER_OF_DESKTOPS -> _NET_NUMBER_OF_DESKTOPS とした。

- 一貫性を考えて _NET_WM_VISIBLE_NAME_STRING -> _NET_WM_VISIBLE_NAME とした。

- _NET_WM_STATE について、どのような拡張が許されるのか説明を追加した。また、同プロパティの「設定されている」「設定されていない」に関する説明も追加した。

- 綴りを調査し、多くの誤植を訂正。

- 一貫性を考えて UTF8 -> UTF-8 とした。

- ICCCM と UTF-8 の参考文献を追加した(未完成)。

- 欠けていたデータとイベントの型式を追加。

- _NET_SUPPORTING_WM_CHECK の説明を明確にした。

- _NET_CLOSE_WINDOW メッセージの型式表示を修正した。

### 1.0pre1 からの変更点

- Gnome で(多分)使われるファイル・マネージャの振る舞いに関する「実装のための覚え書」を削除した。

- 実装のための覚え書の中にある「ウィンドウの移動」の項を改訂した。(訳註：その後、「ウィンドウのジオメトリ」に変更。)

### 1.9f からの変更点

- 最初の公開版に向けて(for first accepted release訳註：要確認)、1.9XX -> 1.0preXX と版番号を改訂した。

- 本仕様を採用する際の前提条件についての記述を追加。

- 一貫性を考えて、_NET_CURRENT_DESKTOP の型式表示を整えた。

- 一貫性を考えて、_NET_ACTIVE_WINDOW の型式表示を整えた。重複した文章を削除した。

- 一貫性を考えて、_NET_WM_DESKTOP の型式表示を整えた。

- 実装のための覚え書の中に「反応しないプロセスの強制終了」の項を追加。_NET_WM_PID と _NET_WM_PING の説明文では、この項を参照している。

- _NET_WM_MOVERESIZE における x_root と y_root の意味が明確になった。

- 貢献者の一覧を追加。

### 1.9e からの変更点

- _NET_WM_VISIBLE_NAME_STRING を追加。

- _NET_NUMBER_OF_DESKTOPS と _NET_DESKTOP_NAMES を合わせて使う場合について、曖昧さが残らないようにした。

- 一貫性を考えて、_NET_WM_MOVERESIZE の「format」を 32 とした。

- _NET_PROPERTIES を削除。

- _NET_WM_MOVERESIZE から註釈を削除。

### 1.9d からの変更点

- _NET_VIRTUAL_ROOTS を追加。

- ICCCM に則ったウィンドウの移動について、記述を追加した。

- _NET_WM_HANDLED_ICONS を追加。

- _NET_SUPPORTING_WM_CHECK を追加。

- 活性化の度合いに関する記述を削除。(訳註：「1.9b からの変更点」にて、_NET_ACTIVE_WINDOW クライアント・メッセージに活性化の度合いが追加されている。)

### 1.9c からの変更点

- ヒントを２つの X プロパティに格納するやり方を削除。Jim Gettys の指摘によれば、ラウンド・トリップ(サーバとの情報の往復)を減らして実行効率を改善するには、Xlib のルーチンを使った方が良いとのこと。

- _NET_DESKTOP_VIEWPORT がピクセル単位であることを明確にした。(訳註：要確認。現在そのような記述は無い。「1.0pre3 からの変更点」で書き直している。)

- _NET_DESKTOP_VIEWPORT が配列になった。配列の各要素が各デスクトップに対応し、異なるデスクトップの上に異なるアクティブ・ビューポートが存在できるようになった。

- _NET_WM_STRUT は、クライアントが可視状態であるデスクトップにおいてのみ適用されるようになった。

- RFC 2119 の用語を導入し、ウィンドウ・マネージャ、ページャ、アプリケーションの役割を明確にするよう試みた。

- _NET_WM_NAME を追加。

- _NET_DESKTOP_NAMES が UTF-8 の文字列になった。

- デスクトップの番号が 0 から始まるようになった。

- _NET_WM_PID を追加。

- _NET_WM_PING プロトコルを追加。

- _NET_WM_STATE_SKIP_TASKBAR を追加。

### 1.9b からの変更点

- _NET_NUMBER_OF_DESKTOPS クライアント・メッセージを削除した。無駄に _NET_{INSERT/DELETE}_DESKTOP と被っていたため。(訳註：実際は逆で、_NET_{INSERT/DELETE}_DESKTOP が削除され、_NET_NUMBER_OF_DESKTOPS が残ったのではないか。要確認。)

- _NET_WM_LAYER と _NET_WM_HINTS を、機能を表す _NET_WM_WINDOW_TYPE ヒントで置き換えた。

- 拡張性を考えて、_NET_WM_STATE をアトムの配列に変更した。

- _NET_WORKAREA と _NET_WM_STRUT についての記述を増やした。

- _NET_WM_SIZEMOVE_NOTIFY プロトコルを削除した。

- _NET_ACTIVE_WINDOW クライアント・メッセージに活性化の度合いを追加した。(訳註：「1.9d からの変更点」で削除。)

- _NET_WM_ICON を追加。

- 私のコメントは [[ ]] に入れ、Marko の草案からのコメントは [[MM: ]] に入れた。

入り口に戻る