Xnest - 入れ子 X サーバ
Xnest [-options]
Xnest
はクライアントでありサーバでもある。
Xnest は、
Xnest
のためにウィンドウやグラフィックスリクエストを管理する
実サーバのクライアントである。
Xnest
は自分のクライアントに対してはサーバである。
Xnest は
クライアントのためにウィンドウやグラフィックスリクエストを管理する。こ
れらのクライアントにとっては、
Xnest
は従来のサーバのように見える。
オプション¶
Xnest
はサンプルサーバ実装の標準オプションを全てサポートしている。
詳しくはシステム付属のオンラインマニュアルの
Xserver の項を参照
すること。これに加えて、以下の引き数も指定することができる。
- -display string
- このオプションは
Xnest
が接続しようとする実サーバのディスプレイ
名を指定する。コマンド行でディスプレイを指定しなければ、
Xnest は環境変数 DISPLAY
を読んでこの情報を取得する。
- -sync
- このオプションを指定すると、Xnest
はウィンドウとグラフィックス操
作を実サーバと同期させる。このオプションはデバッグ時には有効であるが、
サーバの性能はかなり落ちてしまう。どうしても必要な場合以外には使わない
こと。
- -full
- このオプションを指定すると、Xnest
は入れ子サーバを再生成するたび
に実サーバのオブジェクトを再生成し、実サーバへ再接続を行う。サンプルの
サーバ実装においては、このサーバの最後のクライアントが終了したときにサー
バ内の全てのオブジェクトを再生成する。これが行われたとき、デフォルト動
作では Xnest
は新しく生成を行う際はいつも同じトップレベルウィン
ドウと同じ実サーバを維持する。ユーザが完全な再生成を選択した場合には、
トップレベルウィンドウと実サーバへの接続さえも再生成される。
- -class string
- このオプションは入れ子サーバのデフォルトのビジュアルクラスを指定する。
このオプションは標準オプションセットの
-cc
オプションと似ている
が、ビジュアルクラス指定に対して数値ではなく文字列を指定する点が異なる。
文字列は次の6つのうちのいずれかでなければならない:
StaticGray, GrayScale, StaticColor,
PseudoColor, TrueColor, DirectColor. -class
と -cc
が両方とも指定された場合は最後のインスタンスが優先される。入
れ子サーバのデフォルトのビジュアルのクラスは、実サーバのデフォルトのビ
ジュアルのクラスと同じである必要はない。ただし、実サーバにサポートされ
ている必要はある。
Xnest
を起動する前に、
xdpyinfo を使って
実サーバがサポートしているビジュアルクラスのリストを確認すること。ユー
ザがstatic
クラスを選択した場合、個別のクライアントにデフォルトカラー
マップ内の色を割り当てることができる。
- -depth int
- このオプションは、入れ子サーバのデフォルトのビジュアルの深さを指定する。
入れ子サーバのデフォルトビジュアルの深さは実サーバのデフォルトビジュア
ルの深さと同じである必要はない。ただし、実サーバがこの深さをサポートし
ている必要はある。
Xnest
を起動する前に、
xdpyinfo を使って
実サーバがサポートしているビジュアルの深さのリストを確認すること。
- -sss
- このオプションを指定すると、Xnest
はソフトウェアのスクリーンセー
バを使用する。デフォルトでは
Xnest
は実サーバのハードウェアスク
リーンセーバに対応するスクリーンセーバを使用する。
Xnest は実際の
ハードウェア操作はできないため、当然ながらこのスクリーンセーバはソフト
ウェアで作られる。しかし、サンプルサーバのコード内では、これはハードウェ
アのスクリーンセーバとして扱われる。
- -geometry W+H+X+Y
- このオプションは
Xnest
のトップレベルウィンドウについてのジオメ
トリのパラメータを指定する。
これらのウィンドウは入れ子サーバのルート
ウィンドウに対応する。このオプションで指定した幅と高さは、
Xnest
ウィンドウそれぞれの最大の幅と高さとなる。
Xnest
においては、ユー
ザはトップレベルウィンドウのサイズを小さくすることができるが、入れ子サー
バのルートウィンドウのサイズが実際に変わることはない。現在のところ、サ
ンプルサーバ実装には、スクリーンの初期化の後にルートウィンドウのサイズ
を変更する機構は存在しない。これを行うためには、X
プロトコルを拡張する
必要があるだろう。従って、これが可能になることはしばらくはないと思われ
る。このオプションを指定しなければ、
Xnest
は幅と高さを実サーバの
ルートウィンドウの
4/3
のディメンジョンに設定する。
- -bw int
- このオプションは
Xnest
のトップレベルウィンドウの境界幅を指定す
る。整数のパラメータは正の数でなければならない。デフォルトの境界幅は1
である。
- -name string
- このオプションは
Xnest
のトップレベルウィンドウの名前を指定する。
このデフォルト値はプログラム名である。
- -scrns int
- このオプションは入れ子サーバ内に生成されるスクリーンの数を指定する。そ
れぞれのスクリーンに対して、
Xnest
は別々のトップレベルウィンドウ
を生成する。それぞれのスクリーンはクライアントのディスプレイ名指定にドッ
トとスクリーン番号を続けた文字列によって参照される。例えば、
xterm -display :1.1
を実行すると、入れ子サーバ内の番号
:1
のディスプレイの2番目のスクリーン上に
xterm
クライアントが開かれ
る。スクリーンの数はサーバのサンプルコード内にハードコーディングされた
定数によって制限され、この値は通常は3である。
- -install
- このオプションを指定すると、Xnest
は実ウィンドウマネージャを経由
して、自分自身のカラーマップのインストールを行う。これを正しく動作させ
るために、ユーザは一時的に実ウィンドウマネージャを終了させなければなら
ないだろう。デフォルトでは
Xnest
は、カラーマップを実サーバにイ
ンストールしなければならない入れ子クライアントウィンドウを、
Xnest
のトップレベルウィンドウの
WM_COLORMAP_WINDOWS プ
ロパティで管理する。このカラーマップが入れ子サーバのルートウィンドウと
同じビジュアルタイプならば、
Xnest
はこのカラーマップを
Xnest
のトップレベルウィンドウにも関連づける。
これは必ずそうである必要はないので、ウィンドウマネージャが最初に調べる
のは Xnest
のトップレベルウィンドウに関連づけられたカラーマップ
ではなく WM_COLORMAP_WINDOWS
プロパティでなければならない。
残念ながら、ウィンドウマネージャはこの処理はあまり得意ではないので、こ
のオプションが役に立つかもしれない。
- -parent window_id
- このオプションを使用すると、Xnest
は新しいウィンドウを生成せずに
window_id
をルートウィンドウとして使用する。このオプションは
xrx の xnestplugin
が使用する。
使用方法¶
Xnest
の起動は端末エミュレータから
xclock を起動するのと同
じくらい簡単である。実サーバと同じワークステーション上で
Xnest
を実行しようとする場合は、入れ子サーバが監視する専用のソケットのアドレ
スを割り当てなければならない。従って、サーバがワークステーション上で既
に動作中である場合、
Xnest
は新しいディスプレイ番号を使って起動し
なければならない。普通は1つのワークステーション上で複数のサーバが動作
することはないので、大部分のユーザはコマンド行から
Xnest :1
と指定すれば十分だろう。
ワークステーション上で動作するサーバごとに、ディスプレイ番号は1ずつ増
やす必要がある。よって別の
Xnest
を起動するには、コマンド行
で
Xnest :2
と入力する必要がある。
入れ子サーバ内でクライアントを実行するには、各クライアントは入れ子サー
バと同じディスプレイ番号を指定する必要がある。例えば
xterm -display :1
を実行すると、先の例の2番目の入れ子サーバで
xterm を起動する。他
のクライアントは、それぞれの入れ子サーバ内の
xterm から起動する
ことができる。
クライアントとしての
XNEST¶
Xnest
は実サーバや他の実クライアントに対しては別の実クライアント
のように見えるし、そのように振舞う。しかし、
Xnest はかなり資源を
要求するクライアントである。なぜなら、入れ子クライアントからのウィンド
ウとグラフィックスのリクエストのほとんどは、入れ子サーバから実サーバへ
のリクエストとなるためである。従って、
Xnest
と実サーバはローカル
ネットワーク上にあることが望ましく、同じマシン上にあればなお良い。現在
の
Xnest は、実サーバが
shape
拡張をサポートしていることを想定し
ている。この想定を動的に無効にする方法はない。
Xnest は shape 拡
張を組み込まずにコンパイルすることはでき、その場合には実サーバが
shape
拡張をサポートしている必要はない。将来の
Xnest の開発では shape
拡張の動的選択のサポートが考慮されるだろう。
Xnest
は実サーバと同じデフォルトビジュアルを使う必要はないため、
Xnest
クライアントのトップレベルウィンドウは必ず独自のカラーマッ
プを持つ。これは、実サーバが複数カラーマップのインストールを常時サポー
トしていなければ、キーボードやポインタのフォーカスが
Xnest にあ
る間は、他のウィンドウの色は正しく表示されないということである。
Xnest
クライアントのトップレベルウィンドウに関連づけられたカラー
マップは、入れ子サーバが実サーバにインストールしようとしている適切なカ
ラーマップである必要はない。
入れ子クライアントが入れ子サーバのデフォルトビジュアルと異なるビジュア
ルのカラーマップをインストールしようとした場合、
Xnest は入れ子ク
ライアントのトップウィンドウと同じカラーマップを使用する他の入れ子クラ
イアントのトップウィンドウ全てを、実サーバの
Xnest のトップレベ
ルウィンドウの
WM_COLORMAP_WINDOWS
プロパティに格納する。よっ
て、
Xnest
のトップレベルウィンドウを管理する実ウィンドウマネージャ
は、
Xnest
のトップレベルウィンドウに対応するカラーマップではなく
WM_COLORMAP_WINDOWS
プロパティを使うことが重要である。ウィンド
ウマネージャの大部分はこの規約を未だに正しく実装していないようなので、
Xnest
はオプション動作として、実ウィンドウマネージャを経由して実
サーバにカラーマップをインストールすることができる。ユーザがこのオプショ
ンを選択した場合には、通常は一時的に実ウィンドウマネージャを無効にする
必要がある。なぜなら、このオプションは
Xnest
がカラーマップをイ
ンストールする方法と衝突するからである。
入れ子サーバにおけるキーボードとポインタの制御手続きは、実サーバのキー
ボードとポインタの制御パラメータを変更する。
従って、
Xnest
を起動した後は、実サーバのキーボードとポインタの制
御は
Xnest
の内部デフォルト値に変更される。
Xnest には、自
分のデフォルト値を実サーバに押しつけるのではなく、実サーバからキーボー
ドとポインタの制御パラメータを継承させるコマンド行オプションがおそ
らく必要である。これは将来の課題である。
サーバとしての
XNEST¶
サーバとしての
Xnest
は、クライアントにとっては全く普通のサーバ
に見える。クライアントには自分自身が実サーバと入れ子サーバのどちらの上
で動作しているかを知る方法はない。
既に述べたように、
Xnest
はカスタマイズ時にはユーザにとって非常に
使いやすいサーバである。
Xnest
は、デフォルトのビジュアルクラスと
深さ、スクリーンの数などを設定する多くのコマンド行引き数を受け付け
る。将来的には、
Xnest
はカスタマイズ設定ファイルを読み込むように
なり、自由度はより高くなり、必要なレイアウトも簡単に選択できるようにな
る。残念ながら現在はバッキングストアとセーブアンダーはサポートされてい
ないが、これも
Xnest
の将来の開発では考慮される。
ユーザの立場から考えると、明らかに
Xnest
をサーバとして使うとよ
い状況はフォントの選択するときだけである。
Xnest
は、ローカルでフォ
ントをロードし、それからフォント名を実サーバに渡してリモートでフォント
をロードさせるという方法でフォントを管理する。この方法を使うと、テキス
ト操作の度にグリフのビットイメージをネットワーク上で送ることによる負荷
を回避することができる(本当はこれはバグであるが)。フォントの正しい実装
は
OS
のレイヤに移動させるべきである。このアプローチの結果として、
Xnest
はフォントパスを実サーバに伝えないため、ユーザは2つのフォ
ントパスを意識しなければならない。ここで、ローカルのフォントパスは入れ
子サーバのものであり、リモートのパスは実サーバのものである。このように
なっている理由は、実サーバと入れ子サーバは同じファイルシステム上で動作
する必要をなくしているからである(ファイルシステムが異なると、フォント
パスが互に互換でなくなる)。よって、あるフォントが入れ子サーバのローカ
ルのフォントパスにあった場合、そのフォントが実サーバのリモートのフォン
トパスにも存在する保証はない。
xlsfonts
クライアントは、入れ子サー
バで実行した場合にはローカルのフォントパスのフォントを列挙し、実サーバ
上で実行した場合にはリモートのフォントパスのフォントを列挙する。フォン
トを入れ子サーバで正しくオープンするには、そのフォントがローカルとリモー
ト両方のフォントパスになければならない。これはユーザ自身が確認しなけれ
ばならない。
ビジュアルの深さを複数個サポートしているサーバはうまく動作せず、不意に
クラッシュすることもある。おそらくメモリリークを起こしているためである。
Davor Matic, MIT X Consortium