## X Window System Architecture Overview HOWTO

Daniel
Manrique

    roadmr@entropia.com.mx

芳賀靖史
日本語訳

    yasufumi.haga@nifty.com

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

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

## 序文

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

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

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

## はじめに

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 アーキテクチャでも利用 できるんだ。

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

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

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

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

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

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

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

## ウィンドウマネージャ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ちょうど運よくウィンドウマネージャと一緒にたくさんのツールキットがあって、 それぞれが別々の目標を念頭において設計している。その中でも、 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を使うのかっていう見当を つけているのかどうかということなんだ。

## これまでに得たもの

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

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

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

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

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

## デスクトップ環境を救助

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

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

## 特定のデスクトップ環境

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 コントロールセンター）だ。

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

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

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

## 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 ライブラリを呼び出す。これは実際にプリンタと通信して必要なハードコピーを 作り出すんだ。

## 著作権とライセンス

Copyright (c) 2001 by Daniel Manrique

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

## 日本語版謝辞

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