X Window System Architecture Overview HOWTO

Daniel Manrique

roadmr@entropia.com.mx 

芳賀靖史 - 日本語訳

yasufumi.haga@nifty.com

Revision History                                                        
Revision 1.0.1           2001年5月22日          Revised by: dm          
文法上の誤りをいくつか修正。Bill Staehle の指摘による。                 
Revision 1.0             2001年5月20日          Revised by: dm          
LDP 初版リリース                                                        

本文書では、X ウィンドウシステムのアーキテクチャを概観し、次のことがら
をより良く理解できるようにする。つまり、その設計や、X とぴったり融合し
て実用的なグラフィカル環境を作り上げているのはどの構成要素かとか、ウィ
ンドウマネージャやツールキットおよびウィジェットライブラリでは、そうい
った構成要素をどう採り入れているのかといったことだ。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Table of Contents
1. 序文
2. はじめに
3. X ウィンドウシステムのアーキテクチャ - その概要
4. ウィンドウマネージャ
5. クライアントアプリケーション
6. ウィジェットライブラリないしはツールキット
7. これまでに得たもの
8. デスクトップ環境を救助
9. 特定のデスクトップ環境
10. すべてはどのように調和しているのか
11. X 搭載機がおくる一日
12. 著作権とライセンス
13. 日本語版謝辞

1. 序文

本文書の目標は X ウィンドウシステムのアーキテクチャを概観することだ。な
ぜそのような設計なのかとか、どのような構成要素が X とぴったり融合して実
用的なグラフィカル環境を提供しているのかとか、そういった構成要素をどの
ように採り入れているのかといったことがより良く理解できるようにしたいと
考えている。

これから概念をいくつか探求していく。それらは今まで何度も触れられてきて
はいるけれども、技術的な予備知識がない人には多少曖昧なままかもしれない
というものだ。例えば、ウィジェットとツールキット、それにウィンドウマネ
ージャとデスクトップ環境といったようなものだ。日々アプリケーションを使
っている間に、これらの構成要素がどうやって相互にやりとりしているのかに
ついても例をいくつか示していく。

この文書はあえてさほど技術指向にならないようにしている。というのも、こ
の文書の基礎になっているのは、テーマに関する著者の（経験した）知識なん
だ。だからもともとは技術的な知識の要らない入門編にと考えていたんだけど
、一方では、いろいろなコメントやもっと良い例や説明、それに技術的な訂正
をしてもらえれば、この文書の役に立つことも確かだ。この文書に関する質問
やコメントはすべて歓迎するよ。それらは以下の宛先にメールしてもらえれば
届くようになっている。 roadmr@entropia.com.mx <mailto:
roadmr@entropia.com.mx>

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2. はじめに

UNIX がまだ珍しかったころに戻ろう。1970年ころのことだ。グラフィカルなユ
ーザーインタフェースはまだ珍奇なもので、研究室（正確にはゼロックスの
PARC （訳注：米国ゼロックスパロアルトリサーチセンター））ではそれをもて
あそんでいたんだ。でもいまでは、競争力をつけたいという望みがあるから、
オペレーティングシステムには GUI （訳注：グラフィカルユーザーインタフェ
ース）サブシステムが必要になっている。 GUI は以前のインタフェースよりも
扱いやすいと思われている。でも UNIX では、これについてはたいして関心が
あるわけじゃない。それは UNIX が伝統的に、ある程度まで非常にユーザーに
厳しく、使いやすさよりも多芸多才な方がはるかに好ましかったからだ。でも
そんな UNIX システムにさえ GUI が欲しくなるような理由がいくつかある。例
えば、 UNIX にマルチタスクっていう性質を与えれば、好きな時に数多くのプ
ログラムを動かすようにさせるっていうのは自然なことだ。 GUI っていうのは
、画面上にものを表示する方法をもっと管理できるようにするものなんだ。だ
から、多くのプログラムを画面上に同時に置いておけるように、より良い仕組
みをもたらしているわけだ。さらに情報によってはグラフィカルな形式で表示
した方がより良い場合もある（グラフィカルな形式でしか表示できないものさ
えある。pr0n（訳注：ネット上のスラングでポルノ画像のこと）や他にも本質
的にグラフィカルなデータなんかだ）。

歴史的に見れば、 UNIX は大学の研究者たちが進歩させてきたものなんだ。良
い例が 1970年代終りごろ UNIX に追加された BSD （訳注：バークレーソフト
ウェアディストリビューション）のネットワーキングコードだ。これはもちろ
ん、カリフォルニア大学バークレー校での精力的な仕事の所産さ。これが外部
に出まわるにつれて、 X ウィンドウシステム（ X ともいうけど、 X ウィンド
ウズじゃない）もまた研究者たちのプロジェクトの成果になった。この X ウィ
ンドウシステムっていうのは、大多数の GUI サブシステムの基礎になっている
もので、Linux や BSD を含めた、最新の UNIX（ unices って複数形の方かな
？）で見られるものだ。そのプロジェクトが、すなわちマサチューセッツ工科
大学（ MIT ）のアテナプロジェクトだ。 

UNIX はその誕生当初から、マルチユーザーで、マルチタスクで、時分割ができ
るオペレーティングシステムだった。さらにネットワーキング技術と結合した
から、ユーザーが遠隔地から接続できるようになり、そのシステム上で作業を
行なえる能力も身に付けた。以前はこれを成し遂げるのに、シリアル接続のダ
ム端末かネットワーク接続（かの有名な telnet ）のいずれかに頼ってたんだ
。

時が来て、最初に UNIX で動かせる GUI システムを開発するようになると、こ
れらの概念は記憶に留められて、その設計と結び付いた。実際 X の設計はかな
り複雑で、よくそれが欠点だと言われてきた。でもその設計のおかげで、何を
やらせてもうまいシステムになってもいるし、GUI を構成している部品すべて
が、どうやって UNIX の下で調和しているのかを説明するにしたがって、なぜ
そうなのかもすっかり明らかになるだろう。

X のアーキテクチャを見てみる前に、本当に簡単だけどその歴史と、どうやっ
て最終的に Linux システム上に乗るまでになったのかを見て回ることが必要だ
。

X はアテナプロジェクトが開発したもので、1984年にリリースされたんだ。
1988年には " X コンソーシアム" っていう団体が X を引き継いで、今に至る
まで X の開発と配布を扱っている。 X の仕様は自由に利用可能だ。これは賢
い手段だよ。だってそのおかげでほとんどあらゆる所に X があるようになった
んだから。こういった次第でXFree86 が生まれてきたわけだ。 XFree86 は X
を実装したもので、自分たちが Linux コンピュータ上で使っているものだ。
XFree86 は他のオペレーティングシステムでも動作する。ナントカBSD系統でも
OS/2 のようなものでも動くし、その他のオペレーティングシステムでも動くか
もしれない。さらにその名前にも関わらず、 XFree86 は他の CPU アーキテク
チャでも利用できるんだ。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

3. X ウィンドウシステムのアーキテクチャ - その概要

X はクライアント-サーバーというアーキテクチャを使って設計された。アプリ
ケーション自身がクライアントだ。アプリケーションはサーバーと通信して、
リクエストを出し、さらにサーバーから情報を受けとる。

X サーバーはディスプレイとクライアントからのサービスリクエストを独占的
に制御し続けている。この点で、このモデルを使う利点はまったく明白だ。ア
プリケーション（つまりクライアント）が知らなきゃいけないのは、どうやっ
てサーバーと通信するかだけであって、実際のグラフィックスディスプレイデ
バイスとの話の詳細には関心を払う必要がないんだ。もっとも基本的なレベル
では、クライアントは、「ここからあそこまで線を描け」とか「このテキスト
文字列を描写しろ、フォントはこれを使って、画面上のこの位置に」とかいう
ものをサーバーに教えるんだ。

これはグラフィックスライブラリを使ってアプリケーションを書くのと、何の
違いもないだろうと思う。でも X のモデルはもっと先を行っている。クライア
ントがサーバーと同じコンピュータになきゃいけないなんて強制はしないんだ
。クライアントとサーバーの間で通信するのに使うプロトコルは、ネットワー
ク越しでも動作できるし、実際「信頼性の高い octet-stream を提供するプロ
セス間通信の機構」ならなんだって動作できるんだ。もちろん、好ましいのは
TCP/IP プロトコルを使って通信することさ。これまで見てきたように、 X の
モデルは実に強力なんだ。これに関する古典的な例としては、プロセッサーを
集中的に使うアプリケーションを Cray コンピュータで動かして、データベー
スモニターを Solaris サーバーで動かして、電子メールアプリケーションを小
型の BSD メールサーバーで動かして、さらにグラフィックスを使ったプログラ
ムをSGIサーバーで動かして、そうしておいてから、自分の Linux ワークステ
ーションの画面で、それらすべての表示を行なうっていうのがある。

これまでのところ、 X サーバーは実際のグラフィックスディスプレイを扱うも
のだということがわかった。さらに、ユーザーが作業している物理的な実際の
コンピュータで動いているのが X サーバーだから、そのユーザーとの実際のや
りとりすべてを実行する責任があるのも X サーバーだ。これにはマウスやキー
ボードの動きを読みとることも入る。この情報はすべてクライアントに中継さ
れるから、クライアントは、もちろんこれに対して反応しなければならないだ
ろうね。

X はその名前にふさわしく、 Xlib という名前のライブラリを提供している。
これは低レベルのクライアント - サーバー通信のタスクすべてを処理してるん
だ。だから明らかだと思うけど、クライアントが仕事をしてしまうには、Xlib
の中にある関数を実行しなきゃならないんだ。

この時点ではすべてがうまく動いてるようだ。出力を目に見える形で出すこと
とデータの入力、クライアントアプリケーション、そしてそれらが互いに通信
する方法、この3つを担当しているサーバーが自分たちにはある。クライアント
とサーバーの間で、相互に仮想的なやりとりがあるとして、その光景を思い描
いてみるとだ、画面上に矩形の領域を割り振ってくれと、クライアントはサー
バーに頼むだろう。クライアントにしてみれば、画面上のどこに自分が表示さ
れているかなんてことはどうでもいいんだ。「横 X ピクセル、縦 Y ピクセル
の大きさの領域をよこせ」ってサーバーに伝えてるだけなんだ。それから関数
を呼び出して、「ここからあそこまで線を引け」とか「画面のこの領域の中で
ユーザーがマウスを動かしているかどうか教えてくれ」とかいったような行動
を起こすんだ。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

4. ウィンドウマネージャ

でもクライアントが画面上の表示エリア（ウィンドウっていうんだ）を操作す
る際に、X サーバーはどうやってそれを処理するのかには触れていなかったね
。 GUI を使ったことがある人なら明白なことなんだけど、「クライアントのウ
ィンドウ」を管理する必要があるんだ。典型的な例としては、ウィンドウを動
かしたり、ちゃんと整列させたり、大きさを変えたり、最大化したり最小化し
たりっていうことができるんだけど、では X サーバーはこれらの仕事をどうや
って処理するんだろうか。答えはね。実は何もしないんだ。

X の基本的な教義の一つに、「仕組みは提供するけど、方針は任せるよ」って
いうのがある。だから、ウィンドウの操作に関する方法（仕組み）は提供する
としても、実際にその操作がどう振舞うのか（方針）は指示しているわけじゃ
ないんだ。

仕組みと方針っていうこの奇妙なものはすべて、まとめると基本的には次のよ
うになる。つまり、画面上の領域を管理する責任は別のプログラムにあるって
ことだ。このプログラムはウィンドウの置き場所を決めたり、ウィンドウの見
え方や位置、それに大きさをユーザーが管理できる仕組みを提供したりするし
、また普通はウィンドウのタイトルや枠、それにボタンといった「飾り付け」
もしたりする。こうやって、ユーザーがウィンドウ自身を管理できるようにす
るんだ。ウィンドウを管理する（訳注：マネージ）このプログラムの名前は（
さあ、当ててみて！）、「ウィンドウマネージャ」っていうんだ。

「 X のウィンドウマネージャはもう一つのクライアントにすぎない。つまりそ
の専門的な特権に恵まれてはいるけれども、 X ウィンドウシステムの一部じゃ
ないということだ。だから、ウィンドウマネージャは一種類だけじゃないんだ
。それどころかウィンドウマネージャにはたくさんの種類があって、ユーザー
がウィンドウとやりとりする方法やウィンドウの配置、飾り付け、それにキー
ボードとカラーマップのフォーカスを、それぞれ別々のやり方やスタイルでサ
ポートしているんだ。」

X のアーキテクチャが提供しているのは、ウィンドウマネージャがウィンドウ
上でこれらの動作すべてを実行する方法であって、ウィンドウマネージャを実
際に提供しているわけじゃないんだ。

もちろんウィンドウマネージャはたくさんあるよ。なぜなら、ウィンドウマネ
ージャは外部の要素だから、自分の好みやウィンドウをどういうふうに見せた
いかとか、動きをどうしたいとか、どこに置きたいかとか、そういったことし
だいで、（どちらかといえば）簡単に書けるんだ。中には単純化し過ぎて不細
工なもの（ twm ）もあれば、けばけばしくて台所の流し以外ならなんでも入っ
てるようなもの（ enlightenment ）もある。それにその中間にもあらゆるもの
がある。fvwm, amiwm, icewm, windowmaker, afterstep, sawfish, kwm それに
他にも数え切れない。好みが違えばその数だけウィンドウマネージャがあるっ
てことさ。

ウィンドウマネージャっていうのは「メタクライアント」だ。その一番基本的
な任務は他のクライアントを管理することなんだ。ほとんどのウィンドウマネ
ージャは機能を2、3追加している（し、数多くの機能追加をしているものもあ
る）。でも大半のウィンドウマネージャにありそうな機能性の一つが、アプリ
ケーションを起動する方法だ。中にはコマンドボックスを用意して、そこでユ
ーザーが標準的なコマンド（これを使ってクライアントアプリケーションを起
動できる）をタイプできるようにしているものもある。他には、素敵なある種
のアプリケーション起動メニューがある。これが標準化されているわけではな
いんだけどね。もう一度言うけど、クライアントアプリケーションの起動方法
に関する方針なんか、 X は何も規定していないから、この機能性はクライアン
トプログラムで実装すべきものなんだ。たいていはウィンドウマネージャがこ
の仕事を引き受けてる（そしてウィンドウマネージャによってやり方は違う）
とはいえ、他のクライアントアプリケーションを起動するのが唯一の任務だっ
ていうクライアントアプリケーションがあることは考えられる。プログラムの
起動パッドを考えてみてほしい。そしてもちろん、これまで「プログラム起動
」アプリケーションが大量に作られてきたんだ。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

5. クライアントアプリケーション

ここでしばらくの間、クライアントプログラムに注目してみよう。クライアン
トプログラムをゼロから書きたかったんだって思ってほしい。それも X が用意
している機能だけを使ってだ。 Xlib はめちゃくちゃスパルタンで使いずらい
ライブラリだし、それを使って、ユーザーが使えるように画面にボタンを置い
たり、テキストやあるいは素敵なコントロール（スクロールバーやラジオボッ
クスなんか）を置いたりするのは、恐ろしくこみいったことだっていうことが
、すぐに分かるだろう。

でも嬉しいことに、他の誰かがこれらのコントロールをわざわざプログラムし
てくれて、その結果を使えるような形にして僕達に提供してくれたんだ。ライ
ブラリって形でね。これらのコントロールは普通「ウィジェット」って呼ばれ
てる。そしてもちろん、このライブラリは「ウィジェットライブラリ」さ。そ
こでパラメータをいくつか付けてこのライブラリから関数を呼び出して、ボタ
ンを画面上に出させるわけだ。ウィジェットの例としては、メニューやボタン
、ラジオボタン、スクロールバー、それにキャンバスなんかがある。

「キャンバス」っていうのは面白い類のウィジェットだ。というのは、それが
基本的にクライアントの中のサブエリアになっていて、そこに何かを描けるか
らなんだ。当然だけど、 Xlib を直接使うことはないだろう。なぜって、もし
そうすると、ウィジェットライブラリの邪魔をすることになるだろうからね。
だからキャンバスウィジェットの中に任意のグラフィックスを描く方法はライ
ブラリ自身が用意しているんだ。

このウィジェットライブラリは、ユーザーの動作を入力として解釈するのはも
ちろんだけど、実際に画面上に要素を描画するものだから、使うライブラリに
は主に各クライアントの様々な面や動作に責任があるんだ。開発者の立場から
見れば、ウィジェットライブラリにはある API （関数の集合）もあるから、使
いたいウィジェットライブラリがどれなのかは、その API で決まるのかも知れ
ない。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

6. ウィジェットライブラリないしはツールキット

アテナプロジェクトのために開発した、もともとのウィジェットライブラリは
、もちろんアテナウィジェットライブラリだ。アテナウィジェットともいう。
これはかなり基本的なもので、とても不細工で、今の標準から見れば、直観的
な使い方ができない（例えば、スクロールバーやあるいはスライダーを動かす
のに、ドラッグしないんだ。その代わりに右ボタンをクリックしてスクロール
アップして、左ボタンをクリックしてスクロールダウンするんだ）。それ自体
、最近ではあまり使われない。

ちょうど運よくウィンドウマネージャと一緒にたくさんのツールキットがあっ
て、それぞれが別々の目標を念頭において設計している。その中でも、 Motif
はもっとも初期のツールキットの一つだ。これはオープンソフトウェアファウ
ンデーションが持っている Motif グラフィカル環境の一部だったもので、ウィ
ンドウマネージャとそれに合うツールキットから成っている。でも OSF の歴史
はこの文書の範疇を越えてるから触れないよ。アテナウィジェットの上位にあ
る Motif のツールキットは、1980 年代および 1990 年代初めに広く使われる
ようになったんだ。

最近では、 Motif はツールキットに選ぶほどの人気がなくなっている。フリー
じゃない（し、自由にものも言えない）。それに開発用のライセンスが欲しい
と思っても、 OSF Motif には金がかかる（つまり Motif を使って自分だけの
プログラムをコンパイルするにもっていうことだ）。 Motif をリンクしたバイ
ナリを配布するのは OK なんだけどね。少なくとも Linux のユーザーに一番有
名な Motif アプリケーションは、たぶんネットスケープのナビゲータやコミュ
ニケータ（ Mozilla の前身）だ。

しばらくの間は、利用可能でまともなツールキットは Motif だけだった。だか
ら Motif を使ったソフトウェアは周りにたくさんあるんだ。もちろん Motif
に代わるツールキットの開発も始まって、今では Xforms や FLTK、それに他に
もいくつかあるけど、そういったたくさんのツールキットができている。

最近では Motof のことはさほど聞かなくなっている。特にフリーソフトウェア
の世界ではそうだ。それはライセンスや性能（みんな Motif はとってものろま
だって思ってる）それに特徴の点から、今ではもっと良い選択肢があるからな
んだ。

そんなツールキットの一つが、広く知られているし、幅広く使われてもいる
Gtk だ。これはMotif に代わるべく GIMP プロジェクトが特に産み出したもの
だ（ Gtk が「GIMP ツールキット」の意味だっていうのは、一つありそうだ。
でも広く使われているから、 GNU ツールキットだっていう解釈もできそうだ）
。Gtk は今ではとても人気がある。なぜなら比較的軽量だし、特徴も豊富で、
拡張性もあり、それに全体としてフリーだ（し、何でも言える）からだ。GIMP
のリリース 0.6 では changelog に "Bloatif has been zorched（訳注：水ぶ
くれの Motif をゾーチしたぞ。zorchとは、何かを非常に速く進ませる、とい
う意味のハッカー用語）" という一文を入れた。これは Motif が肥満体質だっ
ていう証なんだ。

最近非常に人気がある別のツールキットが Qt だ。これは KDE プロジェクトが
出現してから、かなり有名になったものだ。このプロジェクトでは GUI の要素
すべてに Qt を利用している。 Qt のライセンス問題や KDE と GNOME の住み
分けについては絶対立ち入らないつもりだ。でも Gtk は Motif を置き換える
んだっていうその歴史が興味深いから、長々と取り上げることにする。 Qt に
ついてはちょっとにしておくよ。だってほんとに人気者なんだから。

最後に、触れておく価値があるもう一つの選択肢に LessTif がある。名前は
Motif の駄洒落なんだけど、フリーでAPIに互換性がある、Motif に代わり得る
ものを目指している。でもはっきりしないのは、（想像だけど）Motif のコー
ドに携わっている人達が自分たちのアプリをある他のツールキットに移植する
にあたって、その人たちのためにフリーの代替品を使いやすくするっていうこ
と以上に、新規開発を行なう時にどこまでLessTifを使うのかっていう見当をつ
けているのかどうかということなんだ。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

7. これまでに得たもの

この時点までで、どういう仕組みで X がクライアント - サーバーのアーキテ
クチャになっているのかがわかっただろう。ただしここでクライアントって言
ってるのは自分たちのアプリケーションプログラムのことだよ。このクライア
ント - サーバーのグラフィックシステムでは、利用可能なウィンドウマネージ
ャがいくつかあって、これが画面上の場所を管理している。自分たちのクライ
アントアプリケーションもあって、そこで自分たちは実際に作業をする。さら
にクライアントは、可能なだけのいろんな種類のツールキットを使ってプログ
ラムできるんだ。

さあ、ここからが混乱するところだ。各ウィンドウマネージャがクライアント
を管理する方法はそれぞれ異なっている。動作や飾り付けはあれとそれでは違
っている。また各クライアントがどのツールキットを使うかは決まってるから
、クライアントは互いにその外見も動作も違ってくる。アプリケーションの作
者は同じツールキットを使って、すべてのアプリケーションを作らなきゃいけ
ないなんてことは何も言っていないんだから、例えばそれぞれ別々のツールキ
ットを使って書いた、6個の異なるアプリケーションをユーザーが走らせること
だって、まったく可能なことなんだ。そしてそのアプリケーションは全部外見
と動作が別々になる。これが混乱を生み出すんだ。だってアプリ同士の動作が
首尾一貫してないんだから。アテナウィジェットで書いたプログラムを使った
ことがあれば、 Gtk を使って書いたものとそっくりだとは言えないのに気づく
だろう。それに外見も使い勝手もこんなに違う、これらのアプリケーションを
全部使うのがめちゃくちゃだってことも思い出すだろう。これはそもそも基本
的に GUI 環境を使う上での利点を否定することになるんだ。

もっと技術的な視点に立てば、多くの異なるツールキットを使うってことは、
資源の使用量が増加するってことだ。最新のオペレーティングシステムでは、
動的共有ライブラリっていう概念をサポートしている。つまり、 Gtk を使って
いるアプリケーションが2、3あって、しかも動的共有ライブラリ版の Gtk があ
れば、ディスク上とメモリ上の両方で、この二つか三つのアプリケーションは
同じ Gtk のコピーを共有するっていう意味だ。これが資源を節約するんだ。他
方、 Gtk のアプリケーションがあり、 Qt のアプリケーションもあり、アテナ
をベースにしたものもあり、ネットスケープといったMotifベースのプログラム
もあり、 FLTK を使っているプログラムもあり、別に XForms を使ったのもあ
るっていうことになると、今度は、六つの異なったライブラリをメモリにロー
ドしていることになる。ツールキットが違ってくれば、ライブラリも違うんだ
。心に留めておいて欲しいんだ。すべてのツールキットは基本的に同じ機能性
を提供しているんだってことをね。

そこには他にも問題がある。プログラムを起動する方法がウィンドウマネージ
ャによっていろいろなんだ。アプリを起動する素敵なメニューがあるのもあれ
ば、そうでないものある。そういったものはコマンド起動ボックスをオープン
するか、あるいはあるキーの組合せを使うか、ないしは xterm を開いてコマン
ドを実行してアプリを起動させるといったことさえ、ユーザーに期待している
んだ。もう一度言うけど、そこには標準化されたものがない。だから混乱する
んだ。

最後に、細かい点がある。まだこの分類では扱っていなかったんだけど、GUI
環境に期待するものなんだ。コンフィギュレーションユーティリティーとか「
コントロールパネル」といったものだ。あるいはグラフィックなファイルマネ
ージャもそうだ。もちろんこれらもクライアントのアプリとして書くこともで
きる。そして典型的なフリーソフトウェアのやり方でいけば、何百ものファイ
ルマネージャがあり、同様に何百ものコンフィギュレーションプログラムがあ
る。これらはたぶん、まったく共通点がないソフトウェア要素を数多く扱わな
きゃならないから、混乱を助長するんだ。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

8. デスクトップ環境を救助

ここに飛び込んでくるのが、デスクトップ環境っていう概念だ。全てのものを
標準化する目的で、装備やガイドラインをデスクトップ環境が一揃い提供して
、前に触れた問題点を最小にするっていうのが、その考え方だ。

このデスクトップ環境っていう概念は、初めて Linux の世界に来た人たちには
目新しいものだ。だって（ウィンドウズやマック OS のような）他のオペレー
ティングシステムには本来あるものだからね。例えばマック OS の場合だと、
これはもっとも初期のグラフィカルユーザーインタフェースの一つだけど、使
っている間はずっと、非常に首尾一貫した外見と使い勝手になっている。例を
あげれば、このオペレーティングシステムは先に触れた細かい点を数多く提供
している。ディフォルトのファイルマネージャ（ファインダー）があり、シス
テム全体のコントロールパネルもあり、アプリケーションは全てが使わなきゃ
いけない（だからみんな同じに見える）唯一のツールキットがある。アプリケ
ーションのウィンドウはシステム（厳密に言えば、そこで動いているウィンド
ウマネージャがあるんだけど）が管理する。最後にガイドラインが一揃いあっ
て、アプリケーションはどうやって動作すべきかを開発者に教えたり、コント
ロールの外見と配置を推奨したり、さらにはシステム上に他のアプリケーショ
ンなどがある場合の動作を提案するといった内容になっている。

それはいいんだけど、「そもそも X の開発者たちは、どうしてそういったこと
をしなかったんだろう」。もっともだ。結局は最初に触れた問題点をすべて避
けていたんだと思う。 X を設計する際に、その創造者たちはできるだけ柔軟性
を持たせることにしたっていうのがその答だ。方針と仕組みのパラダイムに戻
るけど、マック OS は大部分が方針を提供している。仕組みはあるけど、それ
らを使って遊ぶよう、人々を促すわけじゃない。結果として多芸じゃなくなる
。マック OS が自分のウィンドウを管理する方法が気に入らなかったり、ツー
ルキットが必要な関数を提供してくれなかったりすると、ほとんどついてない
ってことになる。以前に見たように、 X ではこんなことは起こらない。柔軟性
の方が複雑さよりも価値があるんだ。

Linux や UNIX 、それに X では、すべてのことは結局合意に達するし、その合
意を守ることになるんだ。例として、 KDE を取り上げよう。 KDE には唯一の
ウィンドウマネージャ（ kwm ）があって、これがウィンドウの動きを管理し制
御している。 KDE ではあるグラフィックツールキット（ Qt ）を使うことを推
奨している。これは画面上の制御がおよぶ限り、 KDE アプリケーションの外見
をすべて同じにするためなんだ。 KDE では環境に特化したライブラリ（
kdelibs ）を提供して、Qt をもっと拡張している。これはメニューや "about"
ボックス、プログラムのツールバー、プログラム間通信、印刷、ファイルの選
択、それにその他のことといったような、共通の作業を実行するためなんだ。
このおかげでプログラマの作業はより簡単になるし、こういった専門的な特色
が動作する方法を標準化させることにもなる。 KDE では設計と動作に関するガ
イドラインもプログラマに提供している。もし全員がこのガイドラインに従え
ば、 KDE の下で動くプログラムは、外見と動きの両方とも非常に似たものにな
るだろうっていう考えなんだ。最後に、 KDE が環境の一部として提供している
のが、アプリケーション起動パネル（ kpanel ）、標準のファイルマネージャ
（現時点では konqueror ）、そしてコンフィギュレーションユーティリティ（
コントロールパネル）だ。このコントロールパネルからは、使用環境の多くの
側面が管理できる。デスクトップの背景やウィンドウのタイトルバーの色を設
定することから始まって、ハードウェアのコンフィギュレーションまでだ。

KDE のパネルは MS ウィンドウズのタスクバーと質的には似たものだ。アプリ
ケーションを起動する中心点になってるし、「アプレット」っていう小さなア
プリケーションがそのパネル内に表示されるようにもなっている。このおかげ
で、大部分のユーザーがそれ無しじゃ生きられない小さな本物の時計といった
ような、機能性が加わっているんだ。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

9. 特定のデスクトップ環境

KDE を例に使ってきたけど、 UNIX システムにとっては、決して一番初期のデ
スクトップ環境だっていうわけじゃない。たぶん、一番古いのは CDE （共通デ
スクトップ環境）だ。 OSF から生まれたもう一つの兄弟なんだ。 CDE の FAQ
によれば、「共通デスクトップ環境は UNIX の標準デスクトップであり、多く
のプラットフォームに対する首尾一貫したアクセスを、エンドユーザーやシス
テム管理者、およびアプリケーション開発者に提供するものである。」ここで
鍵になるのが一貫性だ。でも CDE は必要なだけの豊富な特徴もなく簡単に使え
るものでもなかったんだ。だから、Motif の他に、 CDE も事実上フリーソフト
ウェアの世界から消えてしまって、もっと良い選択肢が取って代わったんだ。

Linux では 2 種類のデスクトップ環境が一番人気がある。 KDE と GNOME だ。
でもそれらが唯一ってわけでもない。インターネットで高速な検索をすれば、
半ダースほどのデスクトップ環境が明らかになるだろうね。いくつか名前をあ
げれば、 GNUStep に ROX, GTK+XFce, UDE もある。これらはすべて以前触れた
基本的な装備を持っている。でも GNOME と KDE がいちばん支持されてきたん
だ。コミュニティからも、企業からもだ。だからそれらがもっとも進んだデス
クトップ環境になっていて、非常に多くのサービスをユーザーとアプリケーシ
ョンに提供しているんだ。

これまで、 KDE とその構成要素がその環境下で特定のサービスを提供している
のをみてきた。けれども、優秀なデスクトップ環境っていうことでいえば、
GNOME はその点ではいくぶん似てるんだ。いちばん違いが明らかなのは、（
KDE には kwm があるけれども） GNOME は特定のウィンドウマネージャを要求
してはいないっていうことだ。 GNOME プロジェクトは常にウィンドウマネージ
ャに寛容であろうとしてきたし、ほとんどのユーザーが自分たちの使っている
ウィンドウマネージャに愛着を抱いているっていうことも認めている。それに
何か別のやりかたでウィンドウを管理するものを使えって強要すれば、その観
客を失うことにもなるだろう。最初 GNOME は Enlightenment っていうウィン
ドウマネージャを推していた。そして今では Sawfish がGNOME のお好みだ。で
も GNOME のコントロールパネルには、いつもウィンドウマネージャの選択ボッ
クスがあったんだ。

この他に、 GNOME は Gtk ツールキットを使っているし、 gnome-libs ってい
う一揃いのライブラリを通じて、高レベルの機能と装備を提供している。
GNOME には独自のプログラミングガイドラインが一揃いある。このガイドライ
ンに準拠したアプリケーション間で、矛盾のない動作を保証するためだ。
GNOME で提供しているのは、パネル（単に「パネル」って呼ぶんだ）、ファイ
ルマネージャ（ gmc、たぶん Nautilus が取って代わろうとしてるけどね）、
それにコントロールパネル（ gnome コントロールセンター）だ。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

10. すべてはどのように調和しているのか

どのデスクトップ環境が一番だって感じてもかまわない、ユーザーにはそれぞ
れ選ぶ自由がある。でも最終的には、KDE 100% のシステムか gnome 100% のシ
ステムを使えば、その環境の外見や使い勝手はかなり首尾一貫したものになる
し、アプリケーションだって相互のやりとりがきわめてうまくいく。さまざま
なツールキットをごちゃ混ぜにしてアプリを書いていた時には、これはほんと
に不可能だったんだ。 Linux の下で、最新のデスクトップ環境が提供している
装備が拡大したおかげで、その他の細かい点もうまくいくようになっている。
コンポーネントのアーキテクチャのようにね（ KDE には Kparts があるし、
GNOME では Bonobo っていうコンポーネントの枠組を使ってる）。これを使え
ば、ワープロのドキュメントの中に生のスプレッドシートやあるいはチャート
を持たせるといったことができるようになる。それにウィンドウズで見かける
印刷環境に似たシステム全体の印刷装備もできるようになる。あるいはスクリ
プト言語だ。ずっと進んだユーザーはこれを使って、アプリケーションを一緒
にくっつけて、面白い方法で相互にやりとりさせたり、協調させたりするプロ
グラムを書くようになるよ。

「デスクトップ環境」っていう UNIX の概念の下だと、ある環境で動いている
プログラムを、そこから別の環境に持っていって動かせるんだ。考えられると
すれば、GNOME で Konqueror を使ったり、 KDE で Gnumeric が使うっていう
ことがある。結局これらはプログラムに過ぎないんだからね。もちろんデスク
トップ環境という考え方全体は一貫している。だから自分の特定の環境に合わ
せて設計したアプリに固執するのは、もっともなことなんだ。でも場違いなよ
うに見えるアプリや、自分の環境の他の部分とうまくやりとりしないようなア
プリを進んでうまく処理しようっていうんなら、やるのは完全に自由さ。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

11. X 搭載機がおくる一日

これは Linux システムに載っている最新のデスクトップ環境下で、典型的な
GNOME セッションがどう進行するかの例だ。X 上で動作していると仮定してい
るけど、他の環境下での動き方と非常に良く似ている。

Linux システムがスタートすると、 X サーバーが立ち上がり、グラフィックデ
バイスの初期化を行なう。そしてクライアントからのリクエストを待つ。最初
に gnome-session というプログラムがスタートして、ワーキングセッションを
用意する。セッションには常にオープンしているアプリケーションや、その画
面上の位置なんかの事柄が含まれている。次にパネルが起動する。パネルは（
通常は）一番下に現れる。これはウィンドウ環境用のダッシュボードのような
ものだ。このパネルでプログラムを起動したり、何が動いているかを見てみた
り、そうでなければ作業環境を管理したりする。次にウィンドウマネージャが
立ち上がってくる。いろんなウィンドウマネージャのどれでもいいんだけど、
今は GNOME を使っているから、この場合は Sawfish を動かすとしよう。最後
にファイルマネージャ（ gmc か Nautilus ）が立ち上がる。このファイルマネ
ージャはデスクトップアイコン（デスクトップに直接現れるやつだ）の体裁を
処理する。この時点で自分の GNOME 環境は準備完了だ。

これまでのところ、動かしたプログラムはすべてクライアントで、 X サーバー
に接続している。この場合、 X サーバーはたまたまクライアントと同じコンピ
ュータにいる。でもすでに見たように、その必要はないんだ。

では、 xterm をオープンしてコマンドをいくつかタイプすることにしよう。
xterm アイコンをクリックすると、パネルが xterm アプリケーションを産み落
とす、あるいは起動するといってもいい。これは別の X のクライアントアプリ
ケーションだ。だから起動すると X サーバーに接続して、何かを表示し始める
。 X サーバーがこの xterm に画面のスペースを割り当てると、ウィンドウマ
ネージャに素敵なタイトルバーで飾り付けをさせて、さらに画面上のどこに置
くかを決めさせるんだ

何かをちょっと見てみよう。パネルにあるネットスケープのアイコンをクリッ
クする。するとブラウザーが立ち上がる。覚えておいて欲しいんだけど、この
ブラウザーは GNOME の装備を使ってないし、 Gtk のツールキットも使ってな
いんだ。だから多少ここでは場違いに見えるね。それにこの環境の残りの部分
とのやりとりも、さほどうまくないしね。それから「ファイル」メニューを開
く。 Motif が画面上のコントロールを提供しているから、その下にある Xlib
を適切に呼び出したり、必要な画面上の要素を描画してメニューを表示したり
、「終了」オプションを選択してアプリケーションをクローズできるようにす
るのは、 Motif ライブラリの仕事なんだ。

今度は Gnumeric っていうスプレッドシートを開いて、何かを始めよう。ある
時点で、前に開いていた xterm 上で何かの作業が必要になる。だから xterm
をクリックする。 Sawfish はそれを見て、ウィンドウを管理する担当だから、
xterm を一番上に持ってきて、それにフォーカスを移す。これで xterm で作業
ができることになる。

そのあと、自分のスプレッドシートに戻って、今度は終ったら自分のドキュメ
ントを印刷したいよね。 Gnumeric は GNOME アプリケーションだから、 GNOME
環境が提供している装備が使えるんだ。印刷する場合は、 Gnumeric は
gnome-print ライブラリを呼び出す。これは実際にプリンタと通信して必要な
ハードコピーを作り出すんだ。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

12. 著作権とライセンス

Copyright (c) 2001 by Daniel Manrique

本文書の複製、配布、ないしは変更は、フリー文書利用許諾契約書 <http://
www.gnu.org/copyleft/fdl.html> （ GNU Free Documentation License ）のバ
ージョン 1.1 ないしはそれ以降の条件下で許可する。ただし、変更不可能部分
が無いこと、表表紙が無いこと、および裏表紙が無いこと。フリー文書利用許
諾契約書の複製は以下のサイトで取得できる。here <http://www.gnu.org/
copyleft/fdl.html>

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

13. 日本語版謝辞

日本語版の翻訳にあたり、訳文等のチェックをしていただいた、高城正平さん
と小林雅典さんにはこの場を借りて御礼申し上げます。

