Loading article…
コンピュータ分野において、X Window System（一般にX11またはXと呼ばれる）は、ビットマップディスプレイ用のネットワーク透過型ウィンドウシステムである。この記事では、X11のプロトコルと技術構造について詳しく解説する。
X はクライアント/サーバー モデルを使用します。Xサーバープログラムは、グラフィカル ディスプレイを備えたコンピュータ上で実行され、さまざまなクライアント プログラムと通信します。X サーバーは、ユーザーとクライアント プログラムの間に入って、TCP ポート 6000 とディスプレイ番号[ 1 ]でクライアント プログラムからのグラフィカル出力 (ウィンドウ) の要求を受け付け、それをユーザー (ディスプレイ) に表示し、ユーザー入力 (キーボード、マウス) を受け取ってクライアント プログラムに送信します。
Xでは、サーバーはユーザーのコンピューター上で動作し、クライアントはリモートマシン上で動作する場合があります。この用語は、クライアントが通常ユーザーのローカルコンピューター上で動作し、サーバーがリモートコンピューター上で動作するという、一般的なクライアント/サーバーシステムの概念とは逆です。Xの用語では、Xプログラムがすべての活動の中心にあるという視点に基づいています。つまり、Xプログラムはアプリケーションからの要求、およびユーザーのマウスとキーボードからの入力を受け付け、応答します。したがって、（リモートコンピューター上の）アプリケーションは、Xサーバープログラムのクライアントとみなされます。
サーバーとクライアント間の通信プロトコルはネットワーク透過的に動作します。クライアントとサーバーは同じマシン上で動作することも、異なるマシン上で動作することもでき、異なるアーキテクチャやオペレーティングシステムを使用している場合もあります。クライアントとサーバーは、暗号化された接続を介して接続をトンネル化することで、インターネット上で安全に通信できます。 [ 2 ]
ボブ・シャイフラーとジム・ゲティスは、Xの初期原則を以下のように提示した（シャイフラー／ゲティス 1996 に記載）。
最初の原則は、X11の設計中に次のように変更されました。「実際にそれを必要とするアプリケーションが分かっていない限り、新しい機能を追加してはならない。」
Xはそれ以来、これらの原則を概ね遵守してきた。X.Org財団は、実装の拡張と改善を目指しつつ、1987年のオリジナルプロトコルとのほぼ完全な互換性を維持することを念頭に、リファレンス実装を開発している。
サーバーとクライアント間の通信は、ネットワークチャネルを介したパケット交換によって行われます。クライアントは最初のパケットを送信して接続を確立します。サーバーは、接続の承認または拒否、あるいは追加認証の要求を示すパケットを返信することで応答します。接続が承認された場合、承認パケットには、クライアントがサーバーとのその後のやり取りで使用するデータが含まれます。
接続が確立されると、クライアントとサーバーはチャネルを介して4種類のパケットを交換します。
Xサーバーは一連の基本的なサービスを提供します。クライアントプログラムは、サーバーとやり取りすることで、より複雑な機能を実現します。
他のグラフィカルユーザーインターフェースで一般的に「ウィンドウ」と呼ばれるものは、X Window Systemではトップレベルウィンドウと呼ばれます。また、「ウィンドウ」という用語は、別のウィンドウ内に存在するウィンドウ、つまり親ウィンドウのサブウィンドウにも使用されます。ボタン、メニュー、アイコンなどのグラフィック要素はすべて、ウィンドウを使用して実現されます。
ウィンドウは親ウィンドウのサブウィンドウとしてのみ作成できます。これにより、ウィンドウはツリー構造で階層的に配置されます。Xサーバーはツリーのルートとなるルートウィンドウを自動的に作成します。最上位のウィンドウは、ルートウィンドウの直接のサブウィンドウです。ルートウィンドウは画面と同じ大きさで、他のすべてのウィンドウの背後に表示されます。
Xサーバーは、ウィンドウやフォントなどに関するすべてのデータを格納します。クライアントはこれらのオブジェクトの識別子（サーバーとのやり取りで名前として使用できる整数）を知っています。たとえば、クライアントがウィンドウを作成したい場合、サーバーに作成を要求し、（成功した場合）サーバーが新しく作成されたウィンドウに関連付けた識別子を受け取ります。クライアントはこの識別子を使用して、たとえばウィンドウに文字列を描画するように要求することができます。
識別子はクライアントだけでなくサーバーにも固有です。例えば、異なるクライアントによって作成されたウィンドウであっても、同じ識別子を持つウィンドウは存在しません。クライアントは、たとえ別のクライアントによって作成されたオブジェクトであっても、その識別子があれば任意のオブジェクトにアクセスできます。
すべてのウィンドウには、あらかじめ定義された属性セットとプロパティセットがあり、これらはすべてXサーバーに保存され、適切なリクエストを介してクライアントからアクセスできます。属性は、ウィンドウのサイズ、位置、背景色など、ウィンドウに関するデータです。プロパティは、ウィンドウに付随するデータです。属性とは異なり、プロパティはXコアプロトコルのレベルでは意味を持ちません。クライアントは、ウィンドウのプロパティに任意のデータを格納できます。
プロパティは、名前、型、値によって特徴付けられます。プロパティは、命令型プログラミング言語の変数に似ており、アプリケーションは指定された名前と型の新しいプロパティを作成し、そこに値を格納できます。プロパティはウィンドウに関連付けられます。同じ名前のプロパティでも、型や値が異なる場合は、異なるウィンドウ上に存在できます。
プロパティは主にクライアント間の通信に使用されます。例えば、`name` というプロパティにはWM_NAMEウィンドウの名前が格納されます。ウィンドウマネージャは通常このプロパティを読み取り、ウィンドウの上部にウィンドウの名前を表示します。
このxpropプログラムはウィンドウのプロパティを表示できます。特に、xprop -rootルートウィンドウのプロパティを表示します。これには、Xリソース（プログラムのパラメータ）が含まれます。
イベントとは、サーバーがクライアントに送信するパケットであり、クライアントにとって関心のある何らかの事象が発生したことを通知するものです。クライアントはサーバーに対し、別のクライアントにイベントを送信するよう要求できます。これはクライアント間の通信に使用されます。例えば、クライアントが現在選択されているテキストを要求すると、そのテキストを含むウィンドウを現在処理しているクライアントにイベントが送信されます。
ウィンドウの内容は、特定の条件下（例えば、ウィンドウが覆われた場合など）で「破棄」されることがあります。破棄された内容の領域が再び表示されると、サーバーはExposeイベントを生成し、ウィンドウの一部を描画する必要があることをクライアントに通知します。
その他のイベントは、キーボードやマウスの入力、新しいウィンドウの作成などをクライアントに通知するために使用されます。
一部のイベントは常にクライアントに送信されますが、ほとんどのイベントは、クライアントが事前に関心を示した場合にのみ送信されます。これは、クライアントが特定の種類のイベントにのみ関心を持つ可能性があるためです。たとえば、クライアントはキーボード関連のイベントには関心があっても、マウス関連のイベントには関心がない場合があります。
X Window System の色処理方法は、ユーザーを混乱させる場合があり、これまでいくつかの異なるモードがサポートされてきました。最新のアプリケーションのほとんどはフルカラー(24 ビットカラー、赤、緑、青それぞれに 8 ビット) を使用しますが、古いアプリケーションや特殊なアプリケーションでは、異なるカラーモードが必要になる場合があります。多くの商用特殊アプリケーションでは、擬似カラーが使用されます。
X11プロトコルでは、ほとんどのグラフィック操作において、単一の色を表すためにピクセル値と呼ばれる単一の32ビット符号なし整数を使用します。原色の強度を転送する際には、各色成分に16ビット整数が使用されます。色の表現方法には以下のようなものがありますが、特定のデバイスではすべてがサポートされているとは限りません。
ほとんどのクライアントプログラムは、 Xlibクライアントライブラリを介してサーバーと通信します。Xlibの他に、XCBライブラリはXプロトコルにより近い動作をします。特に、多くのクライアントはXaw、Motif、GTK+、Qtなどのライブラリを使用しており、これらのライブラリはサーバーとのやり取りにXlibを使用しています。Qtは5.0リリースでXlibからXCBに切り替えましたが、クライアントプログラムはこの変更による影響をほとんど受けませんでした。
Xコアプロトコルは、クライアント間の通信のためのメカニズム（ウィンドウプロパティやイベント、特にクライアント間メッセージイベント）を提供します。しかし、こうしたやり取りのためのプロトコルは規定されていません。代わりに、クライアント間の通信に関する別の規約がこれらのプロトコルを規定しています。
クライアント間通信規約マニュアルは、選択によるデータ交換とアプリケーションとウィンドウマネージャ間の相互作用のプロトコルを規定しています。この仕様は難解で分かりにくいと考える人もいます。[ 3 ] [ 4 ]アプリケーションの外観と操作感、および通信の一貫性は、通常、特定のデスクトップ環境に合わせてプログラミングすることで対処されます。
ICE（Inter-Client Exchange Protocol）は、クライアント間の相互作用のためのプロトコルを構築するためのフレームワークを規定しており、プログラマーはこのフレームワークを基に独自のプロトコルを構築できます。特に、Xセッション管理プロトコル（XSMP）はICEをベースとしたプロトコルであり、アプリケーションとセッションマネージャ間の相互作用を管理します。セッションマネージャとは、対話型セッションの終了時にデスクトップの状態を保存し、同じユーザーによる別のセッションが再開された際にその状態を復元する役割を担うプログラムです。
freedesktopの仕様には、ドラッグアンドドロップ規約Xdnd（データを選択して別のウィンドウにドラッグすることでデータを転送するために使用される）や、組み込みアプリケーション規約Xembed（アプリケーションを別のアプリケーションのサブウィンドウで実行する方法を詳細に規定する）など、より新しい規約が含まれています。
X Window System の選択、カットバッファ、ドラッグアンドドロップの仕組みにより、ユーザーはデータをあるウィンドウから別のウィンドウに転送できます。選択とカットバッファは、（一般的に）ユーザーがウィンドウ内のテキストやその他のデータを選択し、別のウィンドウに貼り付ける場合に使用されます。ドラッグアンドドロップは、ユーザーがウィンドウ内で何かを選択し、その選択範囲をクリックして別のウィンドウにドラッグする場合に使用されます。
2つの異なるアプリケーションが2つのウィンドウを処理する可能性があるため、データ転送には、同じXサーバーに接続された複数のクライアント間の通信が必要です。Xコアプロトコルには、選択交換に特有の要求やイベントの種類が含まれていますが、転送は主に、選択転送に特化していない一般的なクライアント間イベント送信とウィンドウプロパティを使用して行われます。
ユーザーはクライアント間でさまざまな種類のデータを転送できます。通常はテキストですが、ピクセルマップ、数値、オブジェクトのリストなども可能です。
選択とドラッグアンドドロップは能動的なメカニズムです。ユーザーがウィンドウ内でデータを選択すると、そのウィンドウを処理するクライアントは、そのデータを要求元のアプリケーションに転送するためのプロトコルを能動的にサポートする必要があります。一方、カットバッファは受動的なメカニズムを提供します。ユーザーがテキストを選択すると、その内容はカットバッファに転送され、ウィンドウを処理するアプリケーションが終了してウィンドウが破棄されても、その内容はカットバッファに残ります。
ウィンドウマネージャとは、ウィンドウやグラフィカルユーザーインターフェースのその他のグラフィック要素の全体的な外観を制御するプログラムです。X Window Systemの外観が異なるインストール環境で異なるのは、主に異なるウィンドウマネージャを使用しているか、ウィンドウマネージャの設定が異なるためです。
ウィンドウマネージャは、ウィンドウの位置の決定、ウィンドウの周囲への装飾的な境界線の配置、アイコンの処理、ウィンドウ外（「背景」）でのマウスクリックの処理、特定のキーストロークの処理などを担当します。
Xサーバーの観点から見ると、ウィンドウマネージャは他のクライアントと同様にクライアントとして動作します。ウィンドウの初期位置とウィンドウの周囲の装飾的な境界線は、ウィンドウマネージャが以下のリクエストを使用して処理します。
ウィンドウマネージャは、最初の要求を使用して、トップレベルウィンドウ（ルートウィンドウの子）のマッピング要求をインターセプトします。他のアプリケーションがトップレベルウィンドウのマッピングを要求すると、サーバーはマッピングを実行せず、代わりにウィンドウマネージャにイベントを送信します。ほとんどのウィンドウマネージャは、ウィンドウの親を変更します。つまり、より大きなトップレベルウィンドウ（フレームウィンドウと呼ばれる）を作成し、元のウィンドウをその子として親を変更します。グラフィカルには、これは元のウィンドウをフレームウィンドウ内に配置することに相当します。フレームウィンドウ内で元のウィンドウが占めていない領域は、ウィンドウの周囲の装飾フレーム（「境界線」と「タイトルバー」）に使用されます。
ウィンドウマネージャは、フレームウィンドウ内でのマウスのクリック操作を管理します。これにより、例えば、ユーザーはウィンドウの境界線やタイトルバーをクリックしてドラッグすることで、ウィンドウを移動したり、サイズを変更したりすることができます。
ウィンドウマネージャは、アイコンやグラフィカルユーザーインターフェイスの関連する視覚要素も処理します。アイコンはXコアプロトコルのレベルには存在せず、ウィンドウマネージャによって実装されます。例えば、ウィンドウを「アイコン化」する必要がある場合、FVWMウィンドウマネージャはウィンドウのマッピングを解除し、アイコン名用のウィンドウと、場合によってはアイコン画像用の別のウィンドウを作成します。したがって、アイコンの意味と処理は完全にウィンドウマネージャによって決定されます。wm2などの一部のウィンドウマネージャは、アイコンを全く実装していません。
セッションの状態とは、おおまかに言えば、特定の時点における「デスクトップの状態」、つまり、現在のコンテンツを含むウィンドウの集合のことです。より正確には、これらのウィンドウを管理するアプリケーションの集合と、必要に応じてこれらのアプリケーションが管理対象ウィンドウの状態を復元するために必要な情報の集合を指します。Xセッションマネージャと呼ばれるプログラムが、セッションの状態を保存および復元します。
最もよく知られている例として、セッションマネージャを使用すると、ユーザーは対話型セッションからログアウトしても、再度ログインした際にまったく同じ状態のウィンドウを利用できます。この機能を実現するには、セッションマネージャプログラムがログアウト時に実行中のアプリケーション名を保存し、ログイン時にそれらを再度起動する必要があります。アプリケーションの状態も復元されるためには（ウィンドウの内容を復元するために必要です）、アプリケーションはセッションマネージャからの要求に応じて実行状態を保存し、再度起動時にそれを読み込むことができなければなりません。
X Window Systemには、デフォルトのセッションマネージャである が含まれていますxsm。開発者は、特定のデスクトップシステム向けに他のセッションマネージャも作成しています。主な例としては ksmserver、KDE、Xfce、GNOME向けにそれぞれxfce4-session、 、 など があります。gnome-session
X ディスプレイマネージャと呼ばれるプログラムは、X Window System でグラフィカルなログインプロンプトを表示します。より一般的には、ディスプレイマネージャはローカルコンピュータ上で 1 つ以上の X サーバーを実行するか、リモートコンピュータで実行されている X サーバーからの接続を受け入れます。ローカルサーバーはディスプレイマネージャによって起動され、ディスプレイマネージャはそれらに接続してユーザーにログイン画面を表示します。リモートサーバーはディスプレイマネージャとは独立して起動され、ディスプレイマネージャに接続します。この場合、ディスプレイマネージャはグラフィカルなTelnetサーバーのように動作します。X サーバーはディスプレイマネージャに接続でき、ディスプレイマネージャはセッションを開始します。このセッションを利用するアプリケーションはディスプレイマネージャと同じコンピュータ上で実行されますが、入出力は X サーバーが実行されているコンピュータ (ユーザーの目の前のコンピュータまたはリモートコンピュータ) で行われます。
X Window Systemには、基本のディスプレイマネージャとしてXDMが付属しています。その他のディスプレイマネージャには、 GDM（GNOME）、KDM / SDDM（KDE）、WDM （ Window Makerで使用されるWINGsウィジェットセットを使用）、entrecess （ Enlightenment v.17で使用されるアーキテクチャを使用）などがあります。
X の初期のウィジェットツールキットには、 Xaw ( Athena Widget Set、1983 年)、OLIT ( OPEN LOOK Intrinsics Toolkit、1988 年)、XView (1988 年)、Motif (1980 年代)、およびTk が含まれていました。OLIT と XView は、 Sunの旧OpenWindowsデスクトップ環境の基本ツールキットとして機能しました。
Motifは、 Solaris、AIX、HP-UXなどの商用Unixシステムで使用されるデスクトップ環境であるCommon Desktop Environment （CDE）の基本ツールキットを提供します。（Solaris 10にはCDEとGNOMEの両方が含まれており、 2010年時点ではGNOMEが推奨されるデスクトップ環境でした。））
近年開発されたツールキットには、Qt （1991年～、 KDEで使用）、GTK+（1997年～、GNOMEで使用）、wxWidgets（1992年～）、FLTK（1998年～）、FOX（1997年～）、fpGUI（2005年～現在）などがある。
シェイフラーとゲティスは、Xサーバーをシンプルでありながら拡張可能なものとして設計した。そのため、現在では多くの機能がプロトコルの拡張機能によって実現されている。
プロトコルレベルでは、すべての拡張機能に新しいリクエスト/イベント/エラーパケットタイプを割り当てることができます。拡張機能は、クライアントアプリケーションから拡張ライブラリを介してアクセスされます。サーバー設計のモジュール性の欠如により、現在のXサーバー実装に拡張機能を追加することは困難であると報告されています。[ 5 ] XMLプロトコル記述から拡張機能のクライアント側とサーバー側の両方を自動的に生成することは、 XCBプロジェクトの長期目標です。
以下の表は、開発された拡張機能の一部を、導入時期の近さ順に概ね並べたものです。
ICCCMは信じられないほど難解で、一字一句すべて従わなければならないが、それでもうまくいかない。ICCCMへの準拠は、Xツールキット、ウィンドウマネージャ、さらには単純なアプリケーションの実装において最も複雑な試練の一つである。非常に難しいため、多くの利点は準拠の手間をかける価値がない。
は[Unix嫌いのハンドブック]の著者が描写している通りひどいものですが、現代のツールキットやウィンドウマネージャがアプリケーションからその醜さをうまく隠してくれるため、最近では気づきにくいです。
では、サーバーに保存されている可能性のあるすべての情報を読み戻すことはできません (たとえば、X11 プロトコルでは GC の状態を照会することはできません)。このため、モジュール性を実現するのがやや難しくなります。
- X Input拡張機能用ライブラリ