<!DOCTYPE ARTICLE PUBLIC "-//OASIS//DTD DocBook V3.1//EN">
<!--
<!DOCTYPE ARTICLE PUBLIC "-//OASIS//DTD DocBook V4.1//EN">
-->
<article id="XWindow-Overview-HOWTO">
  <artheader>
    <title>X Window System Architecture Overview HOWTO</title>

    <author>
       <firstname>Daniel</firstname>
       <surname>Manrique</surname>
       <affiliation>
          <address><email>roadmr@entropia.com.mx</email> </address>
       </affiliation>
    </author>
<!-- Added for Japanese version -->
  <othercredit lang="ja">
    <firstname>芳賀靖史</firstname>
    <surname></surname>
    <contrib>日本語訳</contrib>
    <affiliation>
      <address>yasufumi.haga@nifty.com</address>
    </affiliation>
</othercredit>

    <revhistory>
       <revision>
         <revnumber>1.0.1</revnumber>
         <date><!-- 2001-05-22 -->2001年5月22日</date>
         <authorinitials>dm</authorinitials>
         <revremark>
	 <!--
                Some grammatical corrections, pointed out by Bill Staehle
		-->
		文法上の誤りをいくつか修正。Bill Staehle の指摘による。
         </revremark>
       </revision>
       <revision>
         <revnumber>1.0</revnumber>
         <date><!-- 2001-05-20 -->2001年5月20日</date>
         <authorinitials>dm</authorinitials>
         <revremark>
	 <!--
           Initial LDP release.
	   -->
	   LDP 初版リリース
         </revremark>
       </revision>
    </revhistory>

    <abstract>
	
       <para>
       <!-- This document provides an overview of the X Window
System's architecture, give a better understanding of its design,
which components integrate with X and fit together to provide a
working graphical environment and what choices are there regarding
such components as window managers, toolkits and widget libraries, and
desktop	environments. -->
        本文書では、X ウィンドウシステムのアーキテクチャを概観し、次のことがら
	をより良く理解できるようにする。つまり、その設計や、X とぴったり
	融合して実用的なグラフィカル環境を作り上げているのはどの構成要素かと
	か、ウィンドウマネージャやツールキットおよびウィジェットライブラリで
	は、そういった構成要素をどう採り入れているのかといったことだ。
       </para>
    </abstract>
  </artheader>



<sect1 id="preface">
<title><!-- Preface -->序文</title>
<para>
<!--
This document aims to provide an overview of the X Window System's
architecture, hoping to give people a better understanding of why it's
designed the way it's designed, which components integrate with X and
fit together to provide a working graphical environment and what
choices are there regarding those components.
-->
本文書の目標は X ウィンドウシステムのアーキテクチャを概観することだ。
なぜそのような設計なのかとか、どのような構成要素が X とぴったり融合して
実用的なグラフィカル環境を提供しているのかとか、そういった構成要素を
どのように採り入れているのかといったことがより良く理解できるようにしたい
と考えている。
</para>
<para>
<!--
We explore several concepts that get mentioned a lot but might be a
bit unclear for those without a technical background, such as widgets
and toolkits, window managers and desktop environments. Some examples
of how these components interact during day-to-day use of applications
are provided.
-->
これから概念をいくつか探求していく。それらは今まで何度も触れられてきては
いるけれども、技術的な予備知識がない人には多少曖昧なままかもしれないと
いうものだ。例えば、ウィジェットとツールキット、それにウィンドウマネージャと
デスクトップ環境といったようなものだ。日々アプリケーションを使っている間に、
これらの構成要素がどうやって相互にやりとりしているのかについても例をいくつか
示していく。
</para>
<para>
<!--
This document is, deliberately, not too technically oriented. It's
based on the author's (empirical) knowledge of the subject, and while
it's primarily meant as a non-technical introduction, it can certainly
benefit from any kind of comments, further examples and explanations,
and technical corrections. The author welcomes all questions and
comments regarding this document and can be reached at <ulink url=&quot;mailto:roadmr@entropia.com.mx&quot;><citetitle>roadmr@entropia.com.mx</citetitle></ulink>.
-->
この文書はあえてさほど技術指向にならないようにしている。というのも、この
文書の基礎になっているのは、テーマに関する著者の（経験した）知識なんだ。
だからもともとは技術的な知識の要らない入門編にと考えていたんだけど、一方では、
いろいろなコメントやもっと良い例や説明、それに技術的な訂正をしてもらえれば、
この文書の役に立つことも確かだ。この文書に関する質問やコメントはすべて歓迎する
よ。それらは以下の宛先にメールしてもらえれば届くようになっている。
<ulink url="mailto:roadmr@entropia.com.mx"><citetitle>roadmr@entropia.com.mx</citetitle></ulink>
</para>
</sect1>

<sect1 id="introduction">
<title><!-- Introduction -->はじめに</title>

<para><!-- Back when UNIX was a new thing, around 1970, graphical user
interfaces were only a weird thing being played with in a laboratory
(Xerox's PARC to be precise). Nowadays, however, any operating system
in hopes of being competitive needs to have a GUI subsystem. GUIs are
supposed to be easier to use. This is not much of a concern under
UNIX, which has traditionally been, to some extent, pretty
user-hostile, preferring versatility over ease of use. However, there
are several reasons why a GUI is desirable even on a UNIX system. For
instance, given UNIX's multitasking nature, it's natural to have a lot
of programs running at any given time. A GUI gives more control over
how things are displayed on-screen, thus providing with better
facilities for having a lot of programs on-screen at the same time.
Also, some kinds of information are better displayed in graphical form
(some, even, can only be displayed in graphical form; like pr0n and
other inherently graphical data).-->
UNIX がまだ珍しかったころに戻ろう。1970年ころのことだ。グラフィカルな
ユーザーインタフェースはまだ珍奇なもので、研究室（正確にはゼロックスの PARC
（訳注：米国ゼロックス パロアルト リサーチセンター））ではそれをもてあそんで
いたんだ。でもいまでは、競争力をつけたいという望みがあるから、オペレーティング
システムには GUI （訳注：グラフィカルユーザーインタフェース）サブシステムが
必要になっている。 GUI は以前のインタフェースよりも扱いやすいと思われて
いる。でも UNIX では、これについてはたいして関心があるわけじゃない。それは 
UNIX が伝統的に、ある程度まで非常にユーザーに厳しく、使いやすさよりも
多芸多才な方がはるかに好ましかったからだ。でもそんな UNIX システムにさえ GUI が
欲しくなるような理由がいくつかある。例えば、 UNIX にマルチタスクっていう
性質を与えれば、好きな時に数多くのプログラムを動かすようにさせるっていう
のは自然なことだ。 GUI っていうのは、画面上にものを表示する方法を
もっと管理できるようにするものなんだ。だから、多くのプログラムを画面上に
同時に置いておけるように、より良い仕組みをもたらしているわけだ。さらに
情報によってはグラフィカルな形式で表示した方がより良い場合もある
（グラフィカルな形式でしか表示できないものさえある。pr0n（訳注：ネット上の
スラングでポルノ画像のこと） や他にも本質的にグラフィカルなデータなんかだ）。
</para>
<para><!-- Historically, UNIX has had a lot of improvements done by
academic types. A good example is the BSD networking code added to it
in the late 1970's, which was, of course, the product of work at
the University of California at
Berkeley. As it turns out, the X Window System (also called X, but
never X Windows), which is the foundation for most GUI subsystems
found in modern UNIX (unices?), Linux and the BSD's included, was also
the result of an academic project, namely the Athena project at the Massachusetts Institute of Technology (MIT). -->
歴史的に見れば、 UNIX は大学の研究者たちが進歩させてきたものなんだ。良い例が
1970年代終りごろ UNIX に追加された BSD 
（訳注：バークレー ソフトウェア ディストリビューション）のネットワーキング
コードだ。これはもちろん、カリフォルニア大学バークレー校での精力的な仕事の
所産さ。これが外部に出まわるにつれて、 X ウィンドウシステム（ X ともいうけど、
X ウィンドウズじゃない）もまた研究者たちのプロジェクトの成果になった。この
X ウィンドウシステムっていうのは、大多数の GUI サブシステムの基礎になっている
もので、Linux や BSD を含めた、最新の UNIX（ unices って複数形の方かな？）で
見られるものだ。そのプロジェクトが、すなわちマサチューセッツ工科大学（ MIT ）
のアテナプロジェクトだ。

</para>
<para><!-- Unix has been a multiuser, multitasking, timesharing operating
system since its beginnings. Also, since the incorporation of
networking technologies, it's had the ability to allow a user to
connect remotely and perform work on the system. Previously this was
accomplished either via dumb serial terminals, or network connections
(the legendary telnet). -->
UNIX はその誕生当初から、マルチユーザーで、マルチタスクで、時分割ができる
オペレーティングシステムだった。さらにネットワーキング技術と結合したから、
ユーザーが遠隔地から接続できるようになり、そのシステム上で作業を行なえる能力も
身に付けた。以前はこれを成し遂げるのに、シリアル接続のダム端末かネットワーク
接続（かの有名な telnet ）のいずれかに頼ってたんだ。
</para>
<para><!-- When the time came to develop a GUI system that could run
primarily under Unix, these concepts were kept in mind and
incorporated into the design. Actually, X has a pretty complex design,
which has often been mentioned as a disadvantage. However, because of
its design, it's also a really versatile system, and this will become
quite clear as we explain how all the parts comprising a GUI under
Unix fit together. -->
時が来て、最初に UNIX で動かせる GUI システムを開発するようになると、
これらの概念は記憶に留められて、その設計と結び付いた。実際 X の設計は
かなり複雑で、よくそれが欠点だと言われてきた。でもその設計のおかげで、
何をやらせてもうまいシステムになってもいるし、GUI を構成している部品
すべてが、どうやって UNIX の下で調和しているのかを説明するにしたがって、
なぜそうなのかもすっかり明らかになるだろう。
</para>
<para><!-- Before taking a look at X's architecture, a really brief tour of
its history, and how it ended up on your Linux system, is in order. -->
X のアーキテクチャを見てみる前に、本当に簡単だけどその歴史と、どうやって
最終的に Linux システム上に乗るまでになったのかを見て回ることが必要だ。
</para>
<para><!-- X was developed by the Athena project, and released in 1984. In
1988 an entity called the &quot;X Consortium&quot; took over X, and to this day
handles its development and distribution. The X specification is
freely available, this was a smart move as it has made X almost
ubiquitous. This is how XFree86 came to be. XFree86 is the
implementation of X we use on our Linux computers. XFree86 also works
on other operating systems, like the *BSD lineage, OS/2 and maybe
others. Also, despite its name, XFree86 is also available for other
CPU architectures. --> 
X はアテナプロジェクトが開発したもので、1984年にリリースされたんだ。1988年には
" X コンソーシアム" っていう団体が X を引き継いで、今に至るまで X の開発と
配布を扱っている。 X の仕様は自由に利用可能だ。これは賢い手段だよ。だって
そのおかげでほとんどあらゆる所に X があるようになったんだから。こういった
次第でXFree86 が生まれてきたわけだ。 XFree86 は X を実装したもので、
自分たちが Linux コンピュータ上で使っているものだ。 XFree86 は他の
オペレーティングシステムでも動作する。ナントカBSD系統でも OS/2 のような
ものでも動くし、その他のオペレーティングシステムでも動くかもしれない。
さらにその名前にも関わらず、 XFree86 は他の CPU アーキテクチャでも利用
できるんだ。
</para>
</sect1>

<sect1 id="arch-overview">
<title><!-- The X Window System Architecture: overview -->
       X ウィンドウシステムのアーキテクチャ - その概要</title>

<para><!-- X was designed with a client-server architecture. The
applications themselves are the clients; they communicate with the
server and issue requests, also receiving information from the server. -->
X はクライアント-サーバーというアーキテクチャを使って設計された。
アプリケーション自身がクライアントだ。アプリケーションはサーバーと通信して、
リクエストを出し、さらにサーバーから情報を受けとる。
</para>
<para><!-- The X server maintains exclusive control of the display and
services requests from the clients. At this point, the advantages of
using this model are pretty clear. Applications (clients) only need to
know how to communicate with the server, and need not be concerned
with the details of talking to the actual graphics display device. At
the most basic level, a client tells the server stuff like &quot;draw a
line from here to here&quot;, or &quot;render this string of text, using this
font, at this position on-screen&quot;. -->
X サーバーはディスプレイとクライアントからのサービスリクエストを
独占的に制御し続けている。この点で、このモデルを使う利点はまったく明白
だ。アプリケーション（つまりクライアント）が知らなきゃいけないのは、
どうやってサーバーと通信するかだけであって、実際のグラフィックスディスプレイ
デバイスとの話の詳細には関心を払う必要がないんだ。もっとも基本的なレベル
では、クライアントは、「ここからあそこまで線を描け」とか「このテキスト
文字列を描写しろ、フォントはこれを使って、画面上のこの位置に」とかいう
ものをサーバーに教えるんだ。
</para>
<para><!-- This would be no different from just using a graphics library to
write our application. However the X model goes a step further. It
doesn't constrain the client being in the same computer as the server.
The protocol used to communicate between clients and server can work
over a network, or actually, any &quot;inter-process communication
mechanism that provides a reliable octet stream&quot;. Of course, the
preferred way to do this is by using the TCP/IP protocols. As we can
see, the X model is really powerful; the classical example of this is
running a processor-intensive application on a Cray computer, a
database monitor on a Solaris server, an e-mail application on a small
BSD mail server, and a visualization program on an SGI server, and
then displaying all those on my Linux workstation's screen. -->
これはグラフィックスライブラリを使ってアプリケーションを書くのと、
何の違いもないだろうと思う。でも X のモデルはもっと先を行っている。
クライアントがサーバーと同じコンピュータになきゃいけないなんて強制は
しないんだ。クライアントとサーバーの間で通信するのに使うプロトコルは、
ネットワーク越しでも動作できるし、実際「信頼性の高い octet-stream を提供する
プロセス間通信の機構」ならなんだって動作できるんだ。もちろん、好ましいのは
TCP/IP プロトコルを使って通信することさ。これまで見てきたように、 X のモデル
は実に強力なんだ。これに関する古典的な例としては、プロセッサーを集中的に使う
アプリケーションを Cray コンピュータで動かして、データベースモニターを 
Solaris サーバーで動かして、電子メールアプリケーションを小型の BSD メール
サーバーで動かして、さらにグラフィックスを使ったプログラムをSGIサーバーで
動かして、そうしておいてから、 自分の Linux ワークステーションの画面で、
それらすべての表示を行なうっていうのがある。
</para>
<para><!-- So far we've seen that the X server is the one handling the
actual graphics display. Also, since it's the X server which runs on
the physical, actual computer the user is working on, it's the X
server's responsibility to perform all actual interactions with the
user. This includes reading the mouse and keyboard. All this
information is relayed to the client, which of course will have to
react to it. -->
これまでのところ、 X サーバーは実際のグラフィックスディスプレイを
扱うものだということがわかった。さらに、ユーザーが作業している物理的な
実際のコンピュータで動いているのが X サーバーだから、そのユーザーとの
実際のやりとりすべてを実行する責任があるのも X サーバーだ。これには
マウスやキーボードの動きを読みとることも入る。この情報はすべてクライアントに
中継されるから、クライアントは、もちろんこれに対して反応しなければ
ならないだろうね。
</para>
<para><!-- X provides a library, aptly called Xlib, which handles all
low-level client-server communication tasks. It sounds obvious that,
then, the client has to invoke functions contained within Xlib to get
work done. -->
X はその名前にふさわしく、 Xlib という名前のライブラリを提供している。
これは低レベルのクライアント - サーバー通信のタスクすべてを処理してるんだ。
だから明らかだと思うけど、クライアントが仕事をしてしまうには 、Xlib の
中にある関数を実行しなきゃならないんだ。
</para>
<para><!-- At this point everything seems to be working fine. We have a
server in charge of visual output and data input, client applications,
and a way for them to communicate between each other. In picturing a
hypothetical interaction between a client and a server, the client
could ask the server to assign a rectangular area on the screen. Being
the client, I'm not concerned with where i'm being displayed on the
screen. I just tell the server &quot;give me an area X by Y pixels in
size&quot;, and then call functions to perform actions like &quot;draw a line
from here to there&quot;, &quot;tell me whether the user is moving the mouse in
my screen area&quot; and so on. -->
この時点ではすべてがうまく動いてるようだ。出力を目に見える形で出すことと
データの入力、クライアントアプリケーション、そしてそれらが互いに通信する
方法、この3つを担当しているサーバーが自分たちにはある。クライアントと
サーバーの間で、相互に仮想的なやりとりがあるとして、その光景を思い描いて
みるとだ、画面上に矩形の領域を割り振ってくれと、クライアントはサーバーに
頼むだろう。クライアントにしてみれば、画面上のどこに自分が表示されているか
なんてことはどうでもいいんだ。「横 X ピクセル、縦 Y ピクセルの大きさの
領域をよこせ」ってサーバーに伝えてるだけなんだ。それから関数を呼び出して、
「ここからあそこまで線を引け」とか「画面のこの領域の中でユーザーがマウスを
動かしているかどうか教えてくれ」とかいったような行動を起こすんだ。
</para>
</sect1>

<sect1 id="window-managers">
<title><!-- Window Managers -->ウィンドウマネージャ</title>

<para><!-- However, we never mentioned how the X server handles
manipulation of the clients' on-screen display areas (called
windows). It's obvious, to anyone who's ever used a GUI, that you need
to have control over the &quot;client windows&quot;. Typically you can move and
arrange them; change size, maximize or minimize windows. How, then,
does the X server handle these tasks? The answer is: it doesn't. -->
でもクライアントが画面上の表示エリア（ウィンドウっていうんだ）を操作する
際に、X サーバーはどうやってそれを処理するのかには触れていなかったね。 
GUI を使ったことがある人なら明白なことなんだけど、「クライアントのウィンドウ」
を管理する必要があるんだ。典型的な例としては、ウィンドウを動かしたり、ちゃんと
整列させたり、大きさを変えたり、最大化したり最小化したりっていうことが
できるんだけど、では X サーバーはこれらの仕事をどうやって処理するんだろうか。
答えはね。実は何もしないんだ。
</para>
<para><!-- One of X's fundamental tenets is &quot;we provide mechanism, but not
policy&quot;. So, while the X server provides a way (mechanism) for window
manipulation, it doesn't actually say how this manipulation behaves
(policy). -->
X の基本的な教義の一つに、「仕組みは提供するけど、方針は任せるよ」って
いうのがある。だから、ウィンドウの操作に関する方法（仕組み）は提供する
としても、実際にその操作がどう振舞うのか（方針）は指示しているわけじゃ
ないんだ。
</para>
<para><!-- All that mechanism/policy weird stuff basically boils down to
this: it's another program's responsibility to manage the on-screen
space. This program decides where to place windows, gives mechanisms
for users to control the windows' appearance, position and size, and
usually provides &quot;decorations&quot; like window titles, frames and buttons,
that give us control over the windows themselves. This program, which
manages windows, is called (guess!) a &quot;window manager&quot;. -->
仕組みと方針っていうこの奇妙なものはすべて、まとめると基本的には
次のようになる。つまり、画面上の領域を管理する責任は別のプログラムに
あるってことだ。このプログラムはウィンドウの置き場所を決めたり、
ウィンドウの見え方や位置、それに大きさをユーザーが管理できる仕組みを
提供したりするし、また普通はウィンドウのタイトルや枠、それにボタンといった
「飾り付け」もしたりする。こうやって、ユーザーがウィンドウ自身を
管理できるようにするんだ。ウィンドウを管理する（訳注：マネージ）
このプログラムの名前は（さあ、当ててみて！）、「ウィンドウマネージャ」
っていうんだ。
</para>
<para><!-- &quot;The window manager in X is just another client &#045;&#045; it is not
part of the X window system, although it enjoys special privileges &#045;&#045;
and so there is no single window manager; instead, there are many,
which support different ways for the user to interact with windows and
different styles of window layout, decoration, and keyboard and
colormap focus.&quot; -->
「 X のウィンドウマネージャはもう一つのクライアントにすぎない。つまり
その専門的な特権に恵まれてはいるけれども、 X ウィンドウシステムの一部じゃ
ないということだ。だから、ウィンドウマネージャは一種類だけじゃないんだ。
それどころかウィンドウマネージャにはたくさんの種類があって、ユーザーが
ウィンドウとやりとりする方法やウィンドウの配置、飾り付け、それに
キーボードとカラーマップのフォーカスを、それぞれ別々のやり方やスタイルで
サポートしているんだ。」
</para>
<para><!-- The X architecture provides ways for a window manager to
perform all those actions on the windows; but it doesn't actually
provide a window manager. -->
X のアーキテクチャが提供しているのは、ウィンドウマネージャがウィンドウ上で
これらの動作すべてを実行する方法であって、ウィンドウマネージャを実際に提供して
いるわけじゃないんだ。
</para>
<para><!-- There are, of course, a lot of window managers, because since
the window manager is an external component, it's (relatively) easy to
write one according to your preferences, how you want windows to look,
how you want them to behave, where do you want them to be, and so on.
Some window managers are simplistic and ugly (twm); some are flashy
and include everything but the kitchen sink (enlightenment); and
everything in between; fvwm, amiwm, icewm, windowmaker, afterstep,
sawfish, kwm, and countless others. There's a window manager for every
taste. -->
もちろんウィンドウマネージャはたくさんあるよ。なぜなら、ウィンドウ
マネージャは外部の要素だから、自分の好みやウィンドウをどういうふうに
見せたいかとか、動きをどうしたいとか、どこに置きたいかとか、そういった
ことしだいで、（どちらかといえば）簡単に書けるんだ。中には単純化し過ぎて
不細工なもの（ twm ）もあれば、けばけばしくて台所の流し以外ならなんでも
入ってるようなもの（ enlightenment ）もある。それにその中間にもあらゆる
ものがある。fvwm, amiwm, icewm, windowmaker, afterstep, sawfish, kwm 
それに他にも数え切れない。好みが違えばその数だけウィンドウマネージャが
あるってことさ。
</para>
<para><!-- A window manager is a &quot;meta-client&quot;, whose most basic mission is
to manage other clients. Most window managers provide a few additional
facilities (and some provide a lot of them). However one piece of
functionality that seems to be present in most window managers is a
way to launch applications. Some of them provide a command box where
you can type standard commands (which can then be used to launch
client applications). Others have a nice application launching menu of
some sort. This is not standardized, however; again, as X dictates no
policy on how a client application should be launched, this
functionality is to be implemented in client programs. While,
typically, a window manager takes on this task (and each one does it
differently), it's conceivable to have client applications whose sole
mission is to launch other client applications; think a program
launching pad. And of course, people have written large amounts of
&quot;program launching&quot; applications. -->
ウィンドウマネージャっていうのは「メタクライアント」だ。その一番基本的な
任務は他のクライアントを管理することなんだ。ほとんどのウィンドウマネージャ
は機能を2、3追加している（し、数多くの機能追加をしているものもある）。でも
大半のウィンドウマネージャにありそうな機能性の一つが、アプリケーションを
起動する方法だ。中にはコマンドボックスを用意して、そこでユーザーが標準的な
コマンド（これを使ってクライアントアプリケーションを起動できる）をタイプ
できるようにしているものもある。他には、素敵なある種のアプリケーション
起動メニューがある。これが標準化されているわけではないんだけどね。
もう一度言うけど、 クライアントアプリケーションの起動方法に関する方針なんか、
 X は何も規定していないから、この機能性はクライアントプログラムで実装すべき
ものなんだ。たいていはウィンドウマネージャがこの仕事を引き受けてる（そして
ウィンドウマネージャによってやり方は違う）とはいえ、他のクライアント
アプリケーションを起動するのが唯一の任務だっていうクライアント
アプリケーションがあることは考えられる。プログラムの起動パッドを考えてみて
ほしい。そしてもちろん、これまで「プログラム起動」アプリケーションが
大量に作られてきたんだ。
</para>
</sect1>

<sect1 id="client-applications">
<title><!-- Client Applications -->クライアントアプリケーション</title>

<para><!-- Let's focus on the client programs for a moment. Imagine you
wanted to write a client program from scratch, using only the
facilities provided by X. You'd quickly find that Xlib is pretty
spartan, and that doing things like putting buttons on screen, text,
or nice controls (scrollbars, radio boxes) for the users, is terribly
complicated. -->
ここでしばらくの間、クライアントプログラムに注目してみよう。クライアント
プログラムをゼロから書きたかったんだって思ってほしい。それも X が用意して
いる機能だけを使ってだ。 Xlib はめちゃくちゃスパルタンで使いずらい
ライブラリだし、それを使って、ユーザーが使えるように画面にボタンを置いたり、
テキストやあるいは素敵なコントロール（スクロールバーやラジオボックスなんか）を
置いたりするのは、恐ろしくこみいったことだっていうことが、すぐに
分かるだろう。
</para>
<para><!-- Luckily, someone else went to the trouble of programming these
controls and giving them to us in a usable form; a library. These
controls are usually known as &quot;widgets&quot; and of course, the library is
a &quot;widget library&quot;. Then I just have to call a function from this
library with some parameters and have a button on-screen. Examples of
widgets include menus, buttons, radio buttons, scrollbars, and
canvases. -->
でも嬉しいことに、他の誰かがこれらのコントロールをわざわざプログラムして
くれて、その結果を使えるような形にして僕達に提供してくれたんだ。ライブラリ
って形でね。これらのコントロールは普通「ウィジェット」って呼ばれてる。そして
もちろん、このライブラリは「ウィジェットライブラリ」さ。そこでパラメータを
いくつか付けてこのライブラリから関数を呼び出して、ボタンを画面上に出させる
わけだ。ウィジェットの例としては、メニューやボタン、ラジオボタン、スクロール
バー、それにキャンバスなんかがある。
</para>
<para><!-- A &quot;canvas&quot; is an interesting kind of widget, because it's
basically a sub-area within the client where i can draw
stuff. Understandably, since I shouldn't use Xlib directly, because
that would interfere with the widget library, the library itself gives
a way to draw arbitrary graphics within the canvas widget. -->
「キャンバス」っていうのは面白い類のウィジェットだ。というのは、それが
基本的にクライアントの中のサブエリアになっていて、そこに何かを描ける
からなんだ。当然だけど、 Xlib を直接使うことはないだろう。なぜって、
もしそうすると、ウィジェットライブラリの邪魔をすることになるだろうからね。
だからキャンバスウィジェットの中に任意のグラフィックスを描く方法は
ライブラリ自身が用意しているんだ。
</para>
<para><!-- Since the widget library is the one actually drawing the
elements on-screen, as well as interpreting user's actions into input,
the library used is largely responsible for each client's aspect and
behavior. From a developer's point of view, a widget library also has
a certain API (set of functions), and that might define which widget
library i'll want to use. -->
このウィジェットライブラリは、ユーザーの動作を入力として解釈するのは
もちろんだけど、実際に画面上に要素を描画するものだから、使うライブラリには
主に各クライアントの様々な面や動作に責任があるんだ。開発者の立場から見れば、
ウィジェットライブラリにはある API （関数の集合）もあるから、使いたい
ウィジェットライブラリがどれなのかは、その API で決まるのかも知れない。
</para>
</sect1>

<sect1 id="toolkits">
<title><!-- Widget Libraries or toolkits -->ウィジェットライブラリ
ないしはツールキット</title>

<para><!-- The original widget library, developed for the Athena Project,
is of course the Athena widget library, also known as Athena
Widgets. It's very basic, very ugly, and the usage is not intuitive by
today's standards (for instance, to move a scrollbar or slider
control, you don't drag it; instead, you click the right button to
scroll up and the left button to scroll down). As such, it's pretty
much not used a lot these days. -->
アテナプロジェクトのために開発した、もともとのウィジェットライブラリは、
もちろんアテナ ウィジェットライブラリだ。アテナウィジェットともいう。
これはかなり基本的なもので、とても不細工で、今の標準から見れば、
直観的な使い方ができない（例えば、スクロールバーやあるいはスライダーを
動かすのに、ドラッグしないんだ。その代わりに右ボタンをクリックしてスクロール
アップして、左ボタンをクリックしてスクロールダウンするんだ）。それ自体、
最近ではあまり使われない。
</para>
<para><!-- Just as it happens with window managers, there are a lot of
toolkits, with different design goals in mind. One of the earliest
toolkits is the well-known Motif, which was part of the Open Software
Foundation's Motif graphical environment, consisting of a window
manager and a matching toolkit. The OSF's history is beyond the scope
of this document.  the Motif toolkit, being superior to the Athena
widgets, became widely used in the 1980's and early 1990's. -->
ちょうど運よくウィンドウマネージャと一緒にたくさんのツールキットがあって、
それぞれが別々の目標を念頭において設計している。その中でも、 Motif は
もっとも初期のツールキットの一つだ。これはオープン ソフトウェア ファウンデー
ションが持っている Motif グラフィカル環境の一部だったもので、ウィンドウ
マネージャとそれに合うツールキットから成っている。でも OSF の歴史はこの文書の
範疇を越えてるから触れないよ。アテナウィジェットの上位にある Motif の
ツールキットは、1980 年代および 1990 年代初めに広く使われるようになったんだ。
</para>
<para><!-- These days, Motif is not a popular toolkit choice. It's not free
(speech), and OSF Motif costs money if you want a developer license
(i.e. to compile your own programs with it), altough it's OK to
distribute a binary linked against Motif. Perhaps the best-known Motif
application, for Linux users at least, is Netscape
Navigator/Communicator (prior to Mozilla). -->
最近では、 Motif はツールキットに選ぶほどの人気がなくなっている。フリーじゃ
ない（し、自由にものも言えない）。それに開発用のライセンスが欲しいと
思っても、 OSF Motif には金がかかる（つまり Motif を使って自分だけの
プログラムをコンパイルするにもっていうことだ）。 Motif をリンクした
バイナリを配布するのは OK なんだけどね。少なくとも Linux のユーザーに
一番有名な Motif アプリケーションは、たぶんネットスケープのナビゲータや
コミュニケータ（ Mozilla の前身）だ。
</para>
<para><!-- For a while Motif was the only decent toolkit available, and
there's a lot of Motif software around. Of course people started
developing alternatives, and there are plenty of toolkits, such as
XForms, FLTK and a few others. -->
しばらくの間は、利用可能でまともなツールキットは Motif だけだった。だから 
Motif を使ったソフトウェアは周りにたくさんあるんだ。もちろん Motif に代わる
ツールキットの開発も始まって、今では Xforms や FLTK、それに他にもいくつか
あるけど、そういったたくさんのツールキットができている。
</para>
<para><!-- Motif is not heard of much these days, specially in the free
software world. The reason is that there are now better alternatives,
in terms of licensing, performance (Motif is widely regarded as quite
a pig) and features. -->
最近では Motof のことはさほど聞かなくなっている。特にフリーソフトウェアの
世界ではそうだ。それはライセンスや性能（みんな Motif はとってものろまだって
思ってる）それに特徴の点から、今ではもっと良い選択肢があるからなんだ。
</para>
<para><!--One such toolkit, the widely known and used Gtk, was
specifically created to replace Motif in the GIMP project (one
possible meaning of Gtk is &quot;GIMP ToolKit&quot;, altough, with its widespread
use, it could be interpreted as the GNU ToolKit). Gtk is now very
popular because it's relatively lightweight, feature-rich, extensible
and totally free (speech). The 0.6 release of the GIMP included
&quot;Bloatif has been zorched&quot; in the changelog. This sentence is a
testament to Motif's bloatedness. -->
そんなツールキットの一つが、広く知られているし、幅広く使われてもいる Gtk だ。
これはMotif に代わるべく GIMP プロジェクトが特に産み出したものだ（ Gtk が
「GIMP ツールキット」の意味だっていうのは、一つありそうだ。でも広く
使われているから、 GNU ツールキットだっていう解釈もできそうだ）。Gtk は
今ではとても人気がある。なぜなら比較的軽量だし、特徴も豊富で、拡張性もあり、
それに全体としてフリーだ（し、何でも言える）からだ。GIMPのリリース 0.6 では
changelog に "Bloatif has been zorched（訳注：水ぶくれの Motif をゾーチした
ぞ。zorchとは、何かを非常に速く進ませる、という意味のハッカー用語）" という
一文を入れた。これは Motif が肥満体質だっていう証なんだ。
</para>
<para><!-- Another very popular toolkit these days is Qt. It was not too
well-known until the advent of the KDE project, which utilizes Qt for
all its GUI elements. We certainly won't get into Qt's licensing
issues and the KDE/GNOME disjunctive. Gtk gets a lengthy mention
because its history as a Motif replacement is interesting; Qt gets a
brief mention because it's really popular. -->
最近非常に人気がある別のツールキットが Qt だ。これは KDE プロジェクト
が出現してから、かなり有名になったものだ。このプロジェクトでは GUI の要素
すべてに Qt を利用している。 Qt のライセンス問題や KDE と GNOME の住み分け
については絶対立ち入らないつもりだ。でも Gtk は Motif を置き換えるんだっていう
その歴史が興味深いから、長々と取り上げることにする。 Qt についてはちょっと
にしておくよ。だってほんとに人気者なんだから。
</para>
<para><!-- Finally, another alternative worth mentioning is LessTif. The
name is a pun on Motif, and LessTif aims to be a free, API-compatible
replacement for Motif. It's not clear to what extent LessTif aims to
be used in new development, rather than just helping those with Motif
code use a free alternative while they (conceivably) port their apps
to some other toolkit. -->
最後に、触れておく価値があるもう一つの選択肢に LessTif がある。名前は 
Motif の駄洒落なんだけど、フリーでAPIに互換性がある、Motif に代わり得る
ものを目指している。でもはっきりしないのは、（想像だけど）Motif のコードに
携わっている人達が自分たちのアプリをある他のツールキットに移植するに
あたって、その人たちのためにフリーの代替品を使いやすくするっていうこと
以上に、新規開発を行なう時にどこまでLessTifを使うのかっていう見当を
つけているのかどうかということなんだ。
</para>
</sect1>

<sect1 id="so-far">
<title><!-- What we have so far -->これまでに得たもの</title>

<para><!-- Up to this point we have an idea of how X has a client-server
architecture, where the clients are our application programs. Under
this client-server graphic system, we have several possible window
managers, which manage our screen real estate; we also have our client
applications, which are where we actually get our work done, and
clients can be programmed using several possible different toolkits. -->
この時点までで、どういう仕組みで X がクライアント - サーバーの
アーキテクチャになっているのかがわかっただろう。ただしここで
クライアントって言ってるのは自分たちのアプリケーションプログラムの
ことだよ。このクライアント - サーバーのグラフィックシステムでは、
利用可能なウィンドウマネージャがいくつかあって、これが画面上の場所を
管理している。自分たちのクライアントアプリケーションもあって、そこで
自分たちは実際に作業をする。さらにクライアントは、可能なだけの
いろんな種類のツールキットを使ってプログラムできるんだ。
</para>
<para><!-- Here's where the mess begins. Each window manager has a
different approach to managing the clients; the behavior and
decorations are different from one to the next. Also, as defined by
which toolkit each client uses, they can also look and behave
differently from each other. Since there's nothing that says authors
have to use the same toolkit for all their applications, it's
perfectly possible for a user to be running, say, six different
applications, each written using a different toolkit, and they all
look and behave differently. This creates a mess because behavior
between the apps is not consistent. If you've ever used a program
written with the Athena widgets, you'll notice it's not too similar to
something written using Gtk. And you'll also remember it's a mess
using all these apps which look and feel so different. This basically
negates the advantage of using a GUI environment in the first place. -->
さあ、ここからが混乱するところだ。各ウィンドウマネージャがクライアントを
管理する方法はそれぞれ異なっている。動作や飾り付けはあれとそれでは
違っている。また各クライアントがどのツールキットを使うかは決まってるから、
クライアントは互いにその外見も動作も違ってくる。アプリケーションの
作者は同じツールキットを使って、すべてのアプリケーションを作らなきゃ
いけないなんてことは何も言っていないんだから、例えばそれぞれ別々の
ツールキットを使って書いた、6個の異なるアプリケーションをユーザーが
走らせることだって、まったく可能なことなんだ。そしてそのアプリケーションは
全部外見と動作が別々になる。これが混乱を生み出すんだ。だって
アプリ同士の動作が首尾一貫してないんだから。アテナウィジェットで書いた
プログラムを使ったことがあれば、 Gtk を使って書いたものとそっくりだ
とは言えないのに気づくだろう。それに外見も使い勝手もこんなに違う、
これらのアプリケーションを全部使うのがめちゃくちゃだってことも
思い出すだろう。これはそもそも基本的に GUI 環境を使う上での利点を否定する
ことになるんだ。
</para>
<para><!-- On a more technical standpoint, using lots of different toolkits
increases resource usage. Modern operating systems support the concept
of dynamic shared libraries. This means that if I have two or three
applications using Gtk, and I have a dynamic shared version of Gtk,
then those two or three applications share the same copy of Gtk, both
on the disk and in memory. This saves resources. On the other hand, if
I have a Gtk application, a Qt application, something Athena-based, a
Motif-based program such as Netscape, a program that uses FLTK and
another using XForms, I'm now loading six different libraries in
memory, one for each of the different toolkits. Keep in mind that all
the toolkits provide basically the same functionality. -->
もっと技術的な視点に立てば、多くの異なるツールキットを使うってことは、
資源の使用量が増加するってことだ。最新のオペレーティングシステムでは、
動的共有ライブラリっていう概念をサポートしている。つまり、 Gtk を使っている
アプリケーションが2、3あって、しかも動的共有ライブラリ版の Gtk があれば、
ディスク上とメモリ上の両方で、この二つか三つのアプリケーションは同じ Gtk の
コピーを共有するっていう意味だ。これが資源を節約するんだ。他方、 Gtk の
アプリケーションがあり、 Qt のアプリケーションもあり、アテナをベースにした
ものもあり、ネットスケープといったMotifベースのプログラムもあり、 FLTK を
使っているプログラムもあり、別に XForms を使ったのもあるっていうことになると、
今度は、六つの異なったライブラリをメモリにロードしていることになる。
ツールキットが違ってくれば、ライブラリも違うんだ。心に留めておいて欲しいんだ。
すべてのツールキットは基本的に同じ機能性を提供しているんだってことをね。
</para>
<para><!-- There are other problems here. The way of launching programs
varies from one window manager to the next. Some have a nice menu for
launching apps; others don't, and they expect us to open a
command-launching box, or use a certain key combination, or even open
an xterm and launch all your apps by invoking the commands. Again,
there's no standarization here so it becomes a mess. -->
そこには他にも問題がある。プログラムを起動する方法がウィンドウマネージャに
よっていろいろなんだ。アプリを起動する素敵なメニューがあるのもあれば、そうで
ないものある。そういったものはコマンド起動ボックスをオープンするか、
あるいはあるキーの組合せを使うか、ないしは xterm を開いてコマンドを実行して
アプリを起動させるといったことさえ、ユーザーに期待しているんだ。もう一度
言うけど、そこには標準化されたものがない。だから混乱するんだ。
</para>
<para><!-- Finally, there are niceties we expect from a GUI environment
which our scheme hasn't covered. Things like a configuration utility,
or &quot;control panel&quot;; or a graphical file manager. Of course, these can
be written as client apps. And, in typical free software fashion,
there are hundreds of file managers, and hundreds of system
configuration programs, which conceivably, further the mess of having
to deal with a lot of disparate software components. -->
最後に、細かい点がある。まだこの分類では扱っていなかったんだけど、GUI 環境に
期待するものなんだ。コンフィギュレーションユーティリティーとか「コントロール
パネル」といったものだ。あるいはグラフィックなファイルマネージャもそうだ。
もちろんこれらもクライアントのアプリとして書くこともできる。そして典型的な
フリーソフトウェアのやり方でいけば、何百ものファイルマネージャがあり、同様に
何百ものコンフィギュレーションプログラムがある。これらはたぶん、まったく
共通点がないソフトウェア要素を数多く扱わなきゃならないから、混乱を助長
するんだ。
</para>
</sect1>

<sect1 id="desktop-environments">
<title><!-- Desktop environments to the rescue -->
デスクトップ環境を救助</title>

<para><!-- Here's where the concept of a desktop environment kicks in. The
idea is that a desktop environment provides a set of facilities and
guidelines aiming to standardizing all the stuff we mentioned so that
the problems we mentioned earlier are minimized. -->
ここに飛び込んでくるのが、デスクトップ環境っていう概念だ。全てのものを標準化す
る目的で、装備やガイドラインをデスクトップ環境が一揃い提供して、前に触れた問題
点を最小にするっていうのが、その考え方だ。
</para>
<para><!-- The concept of a desktop environment is something new to people
coming for the first time to Linux because it's something that other
operating systems (like Windows and the Mac OS) intrinsically
have. For example, MacOS, which is one of the earliest graphical user
interfaces, provides a very consistent look-and-feel during the entire
computing session. For instance, the operating system provides a lot
of the niceties we mentioned: it provides a default file manager (the
finder), a systemwide control panel, and single toolkit that all
applications have to use (so they all look the same). Application
windows are managed by the system (strictly speaking there's a window
manager working there). Finally, there are a set of guidelines that
tell developers how their applications should behave, recommend
control looks and placement, and suggest behaviors according to those
of other applications on the system. All this is done in the sake of
consistency and ease of use. -->
このデスクトップ環境っていう概念は、初めて Linux の世界に来た人たちには目新しい
ものだ。だって（ウィンドウズやマック OS のような）他のオペレーティングシステム
には本来あるものだからね。例えばマック OS の場合だと、これはもっとも初期の
グラフィカルユーザーインタフェースの一つだけど、使っている間はずっと、
非常に首尾一貫した外見と使い勝手になっている。例をあげれば、この
オペレーティングシステムは先に触れた細かい点を数多く提供している。ディフォルト
のファイルマネージャ（ファインダー）があり、システム全体のコントロールパネル
もあり、アプリケーションは全てが使わなきゃいけない（だからみんな同じに見える）
唯一のツールキットがある。アプリケーションのウィンドウはシステム（厳密に
言えば、そこで動いているウィンドウマネージャがあるんだけど）が管理する。
最後にガイドラインが一揃いあって、アプリケーションはどうやって動作すべきかを
開発者に教えたり、コントロールの外見と配置を推奨したり、さらにはシステム
上に他のアプリケーションなどがある場合の動作を提案するといった内容になって
いる。
</para>
<para><!-- This begs the question, &quot;why didn't the X developers do things
that way in the first place?&quot;. It makes sense; after all, it would
have avoided all the problems we mentioned earlier. The answer is that
in designing X, its creators chose to make it as flexible as
possible. Going back to the policy/mechanism paradigm, the MacOS
provides mostly policies. Mechanisms are there, but they don't
encourage people to play with those. As a result I lose versatility;
if I don't like the way MacOS manages my windows, or the toolkit
doesn't provide a function I need, I'm pretty much out of luck. This
doesn't happen under X, altough as seen before, the price of
flexibility is greater complexity. -->
それはいいんだけど、「そもそも X の開発者たちは、どうしてそういったことを
しなかったんだろう」。もっともだ。結局は最初に触れた問題点をすべて避けていた
んだと思う。 X を設計する際に、その創造者たちはできるだけ柔軟性を持たせることに
したっていうのがその答だ。方針と仕組みのパラダイムに戻るけど、マック OS は
大部分が方針を提供している。仕組みはあるけど、それらを使って遊ぶよう、
人々を促すわけじゃない。結果として多芸じゃなくなる。マック OS が自分の
ウィンドウを管理する方法が気に入らなかったり、ツールキットが必要な関数を
提供してくれなかったりすると、ほとんどついてないってことになる。以前に見た
ように、 X ではこんなことは起こらない。柔軟性の方が複雑さよりも価値があるんだ。
</para>
<para><!-- Under Linux/Unix and X, it all comes down to agreeing on stuff
and sticking to it. Let's take KDE for example. KDE includes a single
window manager (kwm), which manages and controls the behavior of our
windows. It recommends using a certain graphic toolkit (Qt), so that
all KDE applications look the same, as far as their on-screen controls
go. KDE further extends Qt by providing a set of environment-specific
libraries (kdelibs) for performing common tasks like creating menus,
&quot;about&quot; boxes, program toolbars, communicating between programs,
printing, selecting files, and other things. These make the
programmer's work easier and standardize the way these special
features behave. KDE also provides a set of design and behavior
guidelines to programmers, with the idea that, if everybody follows
them, programs running under KDE will both look and behave very
similarly. Finally, KDE provides, as part of the environment, a
launcher panel (kpanel), a standard file manager (which is, at the
time being, Konqueror), and a configuration utility (control panel)
from which we can control many aspects of our computing environment,
from settings like the desktop's background and the windows' titlebar
color to hardware configurations. -->
Linux や UNIX 、それに X では、すべてのことは結局合意に達するし、その
合意を守ることになるんだ。例として、 KDE を取り上げよう。 KDE には唯一の
ウィンドウマネージャ（ kwm ）があって、これがウィンドウの動きを管理し制御
している。 KDE ではあるグラフィックツールキット（ Qt ）を使うことを推奨
している。これは画面上の制御がおよぶ限り、 KDE アプリケーションの外見を
すべて同じにするためなんだ。 KDE では環境に特化したライブラリ（ kdelibs ）
を提供して、Qt をもっと拡張している。これはメニューや "about" ボックス、
プログラムのツールバー、プログラム間通信、印刷、ファイルの選択、それに
その他のことといったような、共通の作業を実行するためなんだ。このおかげで
プログラマの作業はより簡単になるし、こういった専門的な特色が動作する方法を
標準化させることにもなる。 KDE では設計と動作に関するガイドラインも
プログラマに提供している。もし全員がこのガイドラインに従えば、 KDE の下で
動くプログラムは、外見と動きの両方とも非常に似たものになるだろうっていう
考えなんだ。最後に、 KDE が環境の一部として提供しているのが、アプリケー
ション起動パネル（ kpanel ）、標準のファイルマネージャ（現時点では 
konqueror ）、そしてコンフィギュレーションユーティリティ（コントロール
パネル）だ。このコントロールパネルからは、使用環境の多くの側面が管理できる。
デスクトップの背景やウィンドウのタイトルバーの色を設定することから始まって、
ハードウェアのコンフィギュレーションまでだ。
</para>
<para><!-- The KDE panel is an equivalent to the MS Windows taskbar. It
provides a central point from which to launch applications, and it
also provides for small applications, called &quot;applets&quot;, to be
displayed within it. This gives functionality like the small, live
clock most users can't live without. -->
KDE のパネルは MS ウィンドウズのタスクバーと質的には似たものだ。
アプリケーションを起動する中心点になってるし、「アプレット」っていう小さな
アプリケーションがそのパネル内に表示されるようにもなっている。このおかげで、
大部分のユーザーがそれ無しじゃ生きられない小さな本物の時計といったような、
機能性が加わっているんだ。
</para>
</sect1>

<sect1 id="specific-desktop-environments">
<title><!-- Specific Desktop Environments -->特定のデスクトップ環境</title>

<para><!-- We used KDE as an example, but it's by no means the earliest
desktop environment for Unix systems. Perhaps one of the earliest is
CDE (Common Desktop Environment), another sibling of the OSF. As per
the CDE FAQ: &quot;The Common Desktop Environment is a standard desktop for
UNIX, providing services to end-users, systems administrators, and
application developers consistently across many platforms.&quot; The key
here is consistency. However CDE wasn't as feature-rich and easy as it
needed to be. Along with Motif, CDE has practically disappeared from
the free software world, having been replaced by better alternatives. -->
KDE を例に使ってきたけど、 UNIX システムにとっては、決して一番初期の
デスクトップ環境だっていうわけじゃない。たぶん、一番古いのは CDE
（共通デスクトップ環境）だ。 OSF から生まれたもう一つの兄弟なんだ。 
CDE の FAQ によれば、「共通デスクトップ環境は UNIX の標準デスクトップであり、
多くのプラットフォームに対する首尾一貫したアクセスを、エンドユーザーやシステム
管理者、およびアプリケーション開発者に提供するものである。」ここで鍵になる
のが一貫性だ。でも CDE は必要なだけの豊富な特徴もなく簡単に使えるものでも
なかったんだ。だから、Motif の他に、 CDE も事実上フリーソフトウェアの世界から
消えてしまって、もっと良い選択肢が取って代わったんだ。
</para>
<para><!-- Under Linux, the two most popular desktop environments are KDE
and GNOME, but they're not the only ones. A quick internet search will
reveal about half a dozen desktop environments: GNUStep, ROX,
GTK+XFce, UDE, to name a few. They all provide the basic facilities we
mentioned earlier. GNOME and KDE have had the most support, both from
the community and the industry, so they're the most advanced ones,
providing a large amount of services to users and applications. -->
Linux では 2 種類のデスクトップ環境が一番人気がある。 KDE と GNOME だ。
でもそれらが唯一ってわけでもない。インターネットで高速な検索をすれば、
半ダースほどのデスクトップ環境が明らかになるだろうね。いくつか名前をあげれば、
GNUStep に ROX, GTK+XFce, UDE もある。これらはすべて以前触れた基本的な
装備を持っている。でも GNOME と KDE がいちばん支持されてきたんだ。コミュニティ
からも、企業からもだ。だからそれらがもっとも進んだデスクトップ環境になって
いて、非常に多くのサービスをユーザーとアプリケーションに提供しているんだ。
</para>
<para><!-- We mentioned KDE and the components that provide specific
services under that environment. As a good desktop environment, GNOME
is somewhat similar in that. The most obvious difference is that GNOME
doesn't mandate a particular window manager (the way KDE has kwm). The
GNOME project has always tried to be window manager-agnostic,
acknowledging that most users get really attached to their window
managers, and forcing them to use something that manages windows
differently would detract from their audience. Originally GNOME
favored the Enlightenment window manager, and currently their
preferred window manager is Sawfish, but the GNOME control panel has
always had a window manager selector box. -->
これまで、 KDE とその構成要素がその環境下で特定のサービスを提供している
のをみてきた。けれども、優秀なデスクトップ環境っていうことでいえば、
 GNOME はその点ではいくぶん似てるんだ。いちばん違いが明らかなのは、
（ KDE には kwm があるけれども） GNOME は特定のウィンドウマネージャを
要求してはいないっていうことだ。 GNOME プロジェクトは常にウィンドウマネージャ
に寛容であろうとしてきたし、ほとんどのユーザーが自分たちの使っている
ウィンドウマネージャに愛着を抱いているっていうことも認めている。それに
何か別のやりかたでウィンドウを管理するものを使えって強要すれば、その観客を
失うことにもなるだろう。最初 GNOME は Enlightenment っていうウィンドウ
マネージャを推していた。そして今では Sawfish がGNOME のお好みだ。でも
 GNOME のコントロールパネルには、いつもウィンドウマネージャの選択ボックス
があったんだ。
</para>
<para><!-- Other than this, GNOME uses the Gtk toolkit, and provides a set
of higher-level functions and facilities through the gnome-libs set of
libraries. GNOME has its own set of programming guidelines in order to
guarantee a consistent behavior between compliant applications; it
provides a panel (called just &quot;panel&quot;), a file manager (gmc, altough
it's probably going to be superseded by Nautilus), and a control panel
(the gnome control center). -->
この他に、 GNOME は Gtk ツールキットを使っているし、 gnome-libs っていう
一揃いのライブラリを通じて、高レベルの機能と装備を提供している。 GNOME には
独自のプログラミングガイドラインが一揃いある。このガイドラインに準拠した
アプリケーション間で、矛盾のない動作を保証するためだ。 GNOME で提供している
のは、パネル（単に「パネル」って呼ぶんだ）、ファイルマネージャ（ gmc、
たぶん Nautilus が取って代わろうとしてるけどね）、それにコントロールパネル
（ gnome コントロールセンター）だ。
</para>
</sect1>

<sect1 id="fit-together">
<title><!-- How it all fits together -->
すべてはどのように調和しているのか</title>

<para><!-- Each user is free to choose whichever desktop environment feels
the best.  The end result is that, if you use an all-kde or all-gnome
system, the look and feel of the environment is very consistent; and
your applications all interact between them pretty nicely. This just
wasn't possible when we had apps written in a hodgepodge of different
toolkits. The range of facilities provided by modern desktop
environments under Linux also enable some other niceties, like
component architectures (KDE has Kparts and GNOME uses the Bonobo
component framework), which allow you to do things like having a live
spreadsheet or chart inside a word processing document; global
printing facilities, similar to the printing contexts found in
Windows; or scripting languages, which let more advanced users write
programs to glue applications together and have them interact and
cooperate in interesting ways. -->
どのデスクトップ環境が一番だって感じてもかまわない、ユーザーにはそれぞれ
選ぶ自由がある。でも最終的には、KDE 100% のシステムか gnome 100% のシステムを
使えば、その環境の外見や使い勝手はかなり首尾一貫したものになるし、
アプリケーションだって相互のやりとりがきわめてうまくいく。さまざまな
ツールキットをごちゃ混ぜにしてアプリを書いていた時には、これはほんとに
不可能だったんだ。 Linux の下で、最新のデスクトップ環境が提供している装備が
拡大したおかげで、その他の細かい点もうまくいくようになっている。
コンポーネントのアーキテクチャのようにね（ KDE には Kparts があるし、
 GNOME では Bonobo っていうコンポーネントの枠組を使ってる）。これを使えば、
ワープロのドキュメントの中に生のスプレッドシートやあるいはチャートを持たせる
といったことができるようになる。それにウィンドウズで見かける印刷環境に似た
システム全体の印刷装備もできるようになる。あるいはスクリプト言語だ。
ずっと進んだユーザーはこれを使って、アプリケーションを一緒にくっつけて、
面白い方法で相互にやりとりさせたり、協調させたりするプログラムを書くように
なるよ。
</para>
<para><!-- Under the Unix concept of &quot;desktop environment&quot;, you can have
programs from one environment running in another. I could conceivably
use Konqueror within GNOME, or Gnumeric under KDE. They're just
programs, after all. Of course the whole idea of a desktop environment
is consistency, so it makes sense to stick to apps that were designed
for your particular environment; but if you're willing to cope with an
app that looks &quot;out of place&quot; and doesn't interact with the rest of
your environment, you are completely free to do so. -->
「デスクトップ環境」っていう UNIX の概念の下だと、ある環境で動いている
プログラムを、そこから別の環境に持っていって動かせるんだ。考えられると
すれば、GNOME で Konqueror を使ったり、 KDE で Gnumeric が使うっていう
ことがある。結局これらはプログラムに過ぎないんだからね。もちろんデスクトップ
環境という考え方全体は一貫している。だから自分の特定の環境に合わせて
設計したアプリに固執するのは、もっともなことなんだ。でも場違いなように
見えるアプリや、自分の環境の他の部分とうまくやりとりしないようなアプリを
進んでうまく処理しようっていうんなら、やるのは完全に自由さ。
</para>
</sect1>

<sect1 id="a-day">
<title><!-- A day in the life of an X system -->
X 搭載機がおくる一日</title>

<para><!-- This is an example of how a typical GNOME session goes, under a
modern desktop environment in a Linux system. It's very similar to how
things work under other environments, assuming they work on top of X. -->
これは Linux システムに載っている最新のデスクトップ環境下で、典型的な
GNOME セッションがどう進行するかの例だ。X 上で動作していると仮定している
けど、他の環境下での動き方と非常に良く似ている。
</para>
<para><!-- When a Linux system starts X, the X server comes up and
initializes the graphic device, waiting for requests from
clients. First a program called gnome-session starts, and sets up the
working session. A session includes things such as applications I
always open, their on-screen positions, and such. Next, the panel gets
started. The panel appears at the bottom (usually) and it's sort of a
dashboard for the windowing environment. It will let us launch
programs, see which ones are running, and otherwise control the
working environment. Next, the window manager comes up. Since we're
using GNOME, it could be any of several different window managers, but
in this case we'll assume we're running Sawfish. Finally, the file
manager comes up (gmc or Nautilus). The file manager handles
presentation of the desktop icons (the ones that appear directly on
the desktop). At this point my GNOME environment is ready to work. -->
Linux システムがスタートすると、 X サーバーが立ち上がり、グラフィック
デバイスの初期化を行なう。そしてクライアントからのリクエストを待つ。
最初に gnome-session というプログラムがスタートして、ワーキング
セッションを用意する。セッションには常にオープンしているアプリケーションや、
その画面上の位置なんかの事柄が含まれている。次にパネルが起動する。
パネルは（通常は）一番下に現れる。これはウィンドウ環境用のダッシュボード
のようなものだ。このパネルでプログラムを起動したり、何が動いているかを
見てみたり、そうでなければ作業環境を管理したりする。次にウィンドウマネージャが
立ち上がってくる。 いろんなウィンドウマネージャのどれでもいいんだけど、
今は GNOME を使っているから、この場合は Sawfish を動かすとしよう。
最後にファイルマネージャ（ gmc か Nautilus ）が立ち上がる。このファイル
マネージャはデスクトップアイコン（デスクトップに直接現れるやつだ）の
体裁を処理する。この時点で 自分の GNOME 環境は準備完了だ。
</para>
<para><!-- So far all of the programs that have been started are clients,
connecting to the X server. In this case the X server happens to be in
the same computer, but as we saw before, it need not be. -->
これまでのところ、動かしたプログラムはすべてクライアントで、 X サーバー
に接続している。この場合、 X サーバーはたまたまクライアントと同じ
コンピュータにいる。でもすでに見たように、その必要はないんだ。
</para>
<para><!-- We'll now open an xterm to type some commands. When we click on
the xterm icon, the panel spawns, or launches, the xterm
application. It's another X client application, so it starts, connects
to the X server and begins displaying its stuff. When the X server
assigns screen space for my xterm, it lets the window manager
(Sawfish) decorate the window with a nice titlebar, and decide where
it will be on screen. -->
では、 xterm をオープンしてコマンドをいくつかタイプすることにしよう。
xterm アイコンをクリックすると、パネルが xterm アプリケーションを
産み落とす、あるいは起動するといってもいい。これは別の X のクライアント
アプリケーションだ。だから起動すると X サーバーに接続して、何かを表示
し始める。 X サーバーがこの xterm に画面のスペースを割り当てると、
ウィンドウマネージャに素敵なタイトルバーで飾り付けをさせて、さらに
画面上のどこに置くかを決めさせるんだ
</para>
<para><!-- Let's do some browsing. We click on the Netscape icon on the
panel, and up comes a browser. Keep in mind that this browser doesn't
use GNOME's facilities, nor does it use the Gtk toolkit. It looks a
bit out of place here... also, it doesn't interact very nicely with
the rest of the environment. I'll open the &quot;File&quot; menu. Motif is
providing the on-screen controls, so it's the Motif library's job to
make the appropriate calls to the underlying Xlib, draw the necessary
on-screen elements to display the menu and let me select the &quot;exit&quot;
option, closing the application. -->
何かをちょっと見てみよう。パネルにあるネットスケープのアイコンをクリック
する。するとブラウザーが立ち上がる。覚えておいて欲しいんだけど、この
ブラウザーは GNOME の装備を使ってないし、 Gtk のツールキットも使って
ないんだ。だから多少ここでは場違いに見えるね。それにこの環境の残りの
部分とのやりとりも、さほどうまくないしね。それから「ファイル」メニューを開く。
Motif が画面上のコントロールを提供しているから、その下にある Xlib を
適切に呼び出したり、必要な画面上の要素を描画してメニューを表示したり、
「終了」オプションを選択してアプリケーションをクローズできるように
するのは、 Motif ライブラリの仕事なんだ。
</para>
<para><!-- Now I open a Gnumeric spreadsheet and start doing some stuff. At
some point I need to do some work on the xterm I had open, so I click
on it. Sawfish sees that, and, being in charge of managing windows,
brings the xterm to the top and gives it focus so I can work there. -->
今度は Gnumeric っていうスプレッドシートを開いて、何かを始めよう。ある時点で、
前に開いていた xterm 上で何かの作業が必要になる。だから xterm をクリックする。
Sawfish はそれを見て、ウィンドウを管理する担当だから、 xterm を一番上に
持ってきて、それにフォーカスを移す。これで xterm で作業ができることになる。
</para>
<para><!-- After that, I go back to my spreadsheet, now that I'm finished I
want to print my document. Gnumeric is a GNOME application, so it can
use the facilities provided by the GNOME environment. When I print,
Gnumeric calls the gnome-print library, which actually communicates
with the printer and produces the hard copy I need. -->
そのあと、自分のスプレッドシートに戻って、今度は終ったら自分のドキュメントを
印刷したいよね。 Gnumeric は GNOME アプリケーションだから、 GNOME 環境が
提供している装備が使えるんだ。印刷する場合は、 Gnumeric は gnome-print
ライブラリを呼び出す。これは実際にプリンタと通信して必要なハードコピーを
作り出すんだ。
</para>
</sect1>
<sect1 id=copyright>
<title><!-- Copyright and License -->
著作権とライセンス</title>
<para>Copyright (c) 2001 by Daniel Manrique</para>
   <para>
   <!-- 
    Permission is granted to copy, distribute and/or modify this document
    under the terms of the <ulink 
    url=&quot;http://www.gnu.org/copyleft/fdl.html&quot;><citetitle>GNU Free Documentation
    License</citetitle></ulink>, Version 1.1 or any later version 
    published by the Free Software Foundation with no Invariant Sections, 
    no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
    can be found <ulink url=&quot;http://www.gnu.org/copyleft/fdl.html&quot;>here</ulink>.
    -->
    本文書の複製、配布、ないしは変更は、
    <ulink 
    url="http://www.gnu.org/copyleft/fdl.html"><citetitle>フリー文書利用許諾契約書</citetitle></ulink>
    （ GNU Free Documentation License ）のバージョン 1.1 ないしはそれ以降
    の条件下で許可する。ただし、変更不可能部分が無いこと、表表紙が無いこと、
    および裏表紙が無いこと。フリー文書利用許諾契約書の複製は以下のサイトで
    取得できる。<ulink url="http://www.gnu.org/copyleft/fdl.html">here</ulink>
   </para>

</sect1>

<Sect1 id="thanks">
<Title>日本語版謝辞</Title>
<Para>
日本語版の翻訳にあたり、訳文等のチェックをしていただいた、
高城正平さんと小林雅典さんにはこの場を借りて御礼申し上げます。
</Para>
</sect1>
</article>
