X(1)

名前
X - 移植性の高い、ネットワーク透過なウィンドウシステム

書式

X ウィンドウシステムは広範囲なコンピュータとグラフィックマシン上で稼働 するネットワーク透過なウィンドウシステムである。X コンソーシアムのソフ トウェア配布物はほとんどの ANSI C と POSIX 準拠なシステムで比較的簡単 に構築できる。商用パッケージも広範囲のプラットフォームで利用可能である。

X Consortium は、このソフトウェアに言及する時には次の名称を使用するこ とを求めている。:

X
X ウィンドウシステム(X Window System)
X バージョン 11(X Version 11)
X ウィンドウシステム, バージョン 11(X Window System, Version 11)
X11

X Window System は X Consortium, Inc. の登録商標である。

説明
X ウィンドウシステムのサーバはビットマップディスプレイのあるコンピュー タで稼働する。サーバはユーザの入力と様々なプロセス間通信チャネルを通じ て種々のクライアントからの出力要求を受け付ける。しかし、ごく一般的な場 合にはクライアントプログラムはサーバの動作しているマシンの上で動作する が、クライアントは(異なるアーキテクチャのマシンとオペレーティングシス テムを含めて)他のマシンからも透過的に実行できる。

X は重なりあっている階層構造のサブウィンドウとテキストとグラフィック操作 を、白黒ディスプレイでもカラーディスプレイでもサポートしている。 利用可能な関数の正式な説明については Xlib - C 言語 X インタフェース マニュアル、 X ウィンドウシステムプロトコル 仕様書、 X ツールキットイントリンシクス - C 言語インタフェース マニュアルと 種々のツールの文書を参照すること。

X を使用するプログラムは大変多い。 X コンソーシアムがコアの配布物として提供しているプログラムは以下である。: 端末エミュレータ、xterm; ウィンドウマネージャ、twm; ディスプレイマネージャ、xdm; コンソールリダイレクトプログラム、xconsole; メールインターフェース、xmh; ビットマップエディタ、bitmap; リソース列挙/操作ツール、appres, editres; アクセス制御プログラム、xauth, xhost, と iceauth; ユーザ環境設定プログラム、xrdb, xcmsdb, xset, xsetroot, xstdcmap, xmodmap; 時計、 xclock と oclock; フォント表示、(xfd; フォント、ウィンドウとディスプレイの情報表示ユーティリティ、 xlsfonts, xwininfo, xlsclients, xdpyinfo, xlsatoms, と xprop; スクリーン画像操作ユーティリティ、 xwd, xwud, と xmag; 性能測定ユーティリティ、 x11perf; フォントコンパイラ、 bdftopcf; fslsfonts, fstobdf; フォントサーバと関連ユーティリティ、 xfs, fsinfo, fslsfonts, fstobdf; X Image 拡張実行プログラム, xieperf; mkfontdir; ディスプレイサーバと関連ユーティリティ、Xserver, rgb, mkfontd ir; リモート実行ユーティリティ、 rstart と xon; クリップボードマネージャ、 xclipboard; xkbwatch; キーボード構成記述コンパイラと関連ユーティリティ、 xkbcomp, xkbprint, xkbbell, xkbevd, xkbvleds, と xkbwatch; クライアント停止ユーティリティ、 xkill; 最適化 X プロトコルプロキシ、 lbxproxy; ファイアウォールセキュリティプロキシ、 xfwp; プロキシを制御するプロキシマネージャ、 proxymngr; プロキシを発見するユーティリティ、 xfindproxy; Netscape Navigator のプラグイン, libxrx.so と libxrxnest.so; RX MIME-タイプ用の補助プログラム、 xrx; とスクリーンの全てもしくは一部を再描画するユーティリティ、 xrefresh 。

その他の多くのユーティリティ、ウィンドウマネージャ、ゲーム、ツールキット、 その他は、ユーザによる寄贈ソフトウェアとして X コンソーシアムの配布物 のに含まれているか、インターネット上の anonymous ftp で入手可能である。 詳細は自サイトの管理者に問い合わせること。

はじめに

X サーバの入手とクライアントアプリケーションの初期設定をする方法には、 2 つの主な方法がある。この細かい部分は、稼働中のオペレーティングシ ステムや X の他にウィンドウシステムを使用したいかどうかに依存する。

xdm (X ディスプレイマネージャ)
    X をディスプレイ上で常時実行させたい場合は、自サイトの管理者にそのマシ ンに X ディスプレイマネージャ(X Display Manager) xdm を設定して もらうこと。このプログラムは通常ブート時にシステムによって起動され、サー バが常に実行されユーザがログインできるようにする。xdm が稼働して いる場合は、ログインを促す画面がウィンドウに表示されて、ユーザ名とパス ワードを聞いているだろう。ここで、単に通常の端末と同様にユーザ名とパス ワードをそれぞれ答えてリターンキーを押すこと。間違えた場合は xdm はエラーメッセージを表示してもう一度聞かれる。うまくログインできたら、 xdm は X 環境を開始する。 デフォルトでは、実行可能属性のついた .xsession という名称のファ イルがホームディレクトリにあれば、xdm はこれを初期クライアント (端末エミュレータ、時計、ウィンドウマネージャ、背景ウィンドウやポイン タの速度等を設定するプログラム等)を実行するためのプログラム(またはシェ ルスクリプト)として扱う。

xinit (シェルから手動で起動した場合)
    複数のウィンドウシステムをサポートしているサイトでは、X を手動で開始す るxinit を使用すること。ユーザのマシンがそのような環境であれば、 自サイトの管理者が "x11", "startx", とか "xstart" のような (標準リソー スのロード、ウィンドウマネージャの起動、クロックの表示、端末エミュレー タの起動を行うような)サイト独自のプログラムをちゃんと用意しているはず である。さもなければ、このようなスクリプトを xinit プログラムを 使って構築すること。このユーティリティは、ユーザの指定したプログラムを 実行してサーバを起動し、別のプログラムを実行して使いたいクライアントを 起動させ、その後これらが終わるのを待つ。ユーザの指定したプログラムのそ れぞれもしくは両方はシェルスクリプトなので、インタフェースをよくするた め相当な柔軟性がある。 したがって、xinit はエンドユーザ向けではない。

ディスプレイ名

ユーザから見ると、すべての X サーバは次のような形式で ディスプレイ 名(display name) を保持している。

hostname:displaynumber.screennumber ホスト名:ディスプレイ番号.スクリーン 番号

この情報は、アプリケーションのサーバへの接続方法とデフォルトで使うスク リーンを決める(複数のモニタに表示するとき)ために使われる。

hostname ホスト名
    hostname は物理的にディスプレイが接続されたマシンの名前を指定す る。hostname が与えられなかった場合は、もっとも効率のいい方法としてサー バに接続されているディスプレイが使われる。

displaynumber ディスプレイ番号
    "ディスプレイ(display)" という用語は通常、一般的なキーボードとポインタ (マウス、タブレット等) を共有するモニタの集合を指すために使われる。 ほとんどのワークステーションは 1 つのキーボードのみと 1 つのディスプレ イのみが接続されている。巨大な、マルチユーザシステムではよく複数の人が グラフィックの作業をできるように複数のディスプレイを持つことがよくある。 混乱を避けるために、X サーバがディスプレイを起動するときにそれぞれのディ スプレイに (0 から始まる) display number を割り当てる。ディスプ レイ番号は必ずディスプレイ名に含まれていなければならない。

screennumber スクリーン番号
    ディスプレイによっては 1 つのキーボードとポインタを複数のモニタで共有 していることがある。それぞれのモニタはウィンドウの集合を持っているので、 それぞれのスクリーンに X サーバがディスプレイ起動時に (0 から始まる) screen number を割り当てる。screen number が与えられない場合は screen 0 が使用される。

POSIX システムでは、標準ディスプレイ名は DISPLAY 環境変数に格納される。 この変数は xterm 端末エミュレータによって自動的に設定される。 しかしながら、ネットワーク上の他のマシンにログインするとき、DISPLAY が 使用するディスプレイを指すように設定しなければならない。たとえば、

    % setenv DISPLAY myws:0
    $ DISPLAY=myws:0; export DISPLAY

のようにすること。 xon スクリプトを使用して、リモートマシンで X プログラムを開始す ることができる。そのスクリプトは正しい DISPLAY 環境変数を自動設定する。

最後に、ほとんどの X プログラムは一時的に DISPLAY の内容を上書きする -display displayname のコマンド行オプションを受け付ける。 これは他の人のスクリーンにウィンドウをポップアップさせるためや、 リモートの xterm をコマンド自分のディスプレイに出すために「リモートシェ ル」コマンドの一部として使われることが一般的である。例えば、

    % xeyes -display joesws:0 -geometry 1000x1000+0+0
    % rsh big xterm -display myws:0 -ls </dev/null &

のようにすること。 X サーバは様々な異なる通信チャネル (ネットワークバイトストリーム、共有メモリ 等) との接続を待つ。与えられたサーバへの複数の接続方法があるので、ディ スプレイ名のhostname の部分は (トランスポート層と呼ばれる) チャ ネルの種類を認識するのに使用される。X サーバは一般的に次の接続の種類を サポートしている。:

local
    ディスプレイ名のホスト名部分は空の文字列でなければならない。 例えば: :0, :1, と :0.1 となる。大変効率の良いローカ ル転送が選ばれる。

TCPIP
    ディスプレイ名のホスト名部分はサーバマシンの IP アドレスでなければなら ない。完全なインターネット名、短縮名、と IP アドレスが全て許可される。 例えば: x.org:0, expo:0, 198.112.45.11:0, bigmachine:1, hydra:0.1 となる。

DECnet
    ディスプレイ名のホスト名部分は 1 つのコロンを 2 つのコロンに代えてその後に サーバマシンの nodename を記述したものである。例えば、: myws::0, big::1, hydra::0.1 となる。

アクセス制御
X サーバは複数のタイプのアクセス制御の種類を利用できる。X11 リリース 6 の提供する機構は:
    Host Access	単純なホストベースのアクセス制御。
    MIT-MAGIC-COOKIE-1	平文の "cookies" を共有。
    XDM-AUTHORIZATION-1	安全な DES ベースの秘密鍵。
    SUN-DES-1	Sun の Secure RPC 機構に基づく。
    MIT-KERBEROS-5	Kerberos バージョン 5 のユーザ対ユーザ認証。

xdm はサーバに対する制御を初期化し、ユーザがアクセスできるファイ ルに認証情報を格納する。通常、必ず接続が許されるホストのリストは空であ り、明示的に認証されたクライアントだけがディスプレイに接続できる。 ホストのリストに (xhost で) 項目を追加したときは、サーバはそれらの マシンからの接続についての認証は行わない。xhost の実行は注意すること。

Xlib が認証データを伸長してできたファイルは XAUTHORITY 環 境変数で指定できる。標準はホームディレクトリ内の .Xauthority ファ イルである。 xdm は $HOME/.Xauthority を使用し、 ファイルを作成するか、ユーザがログインする時に認証レコードのファイルが 既にあればこれにマージする。

複数のマシンを使用していてネットワークファイルシステムによってすべての マシン共通のホームディレクトリを共有している場合、認証ファイルについて 心配する必要はなく、システムはデフォルトで正常に動作する。 他方、認証ファイルがマシン依存の場合は、認証ファイルを共有するために単に コピーできる。認証ファイルを管理するために xauth を使用すること。 このプログラムを使うと、レコードを伸長し他のファイルに挿入することがで きる。リモートマシンがローカルマシンとホームディレクトリを共有していな い場合、これを使用するとログイン時にリモートマシンへ認証を送信できる。 NFS経由や ftp を rcp を使用して"暗号化しないで"認証情報を 送信した場合には、ネットワーク盗聴者はこれを"盗む"ことができ、認証され ないアクセスが可能になってしまう点に注意すること。 多くの環境では、これほどのセキュリティ水準は必要ないが、必要であるなら ば、この点が実際に問題になるかどうかを知るために特定の認証データに関す る正確な意味を知る必要がある。アクセス制御の詳細については Xsecurity のオンラインマニュアルを参照すること。

ジオメトリ指定
ハードウェアにより実現されている端末に代わるウィンドウシステムの優位性 の 1 つは、アプリケーションがスクリーン上の特定の大きさ又はその位置の 制限を受ける必要が無いことである。ディスプレイ上のウィンドウのレイアウ トはユーザが実行しているウィンドウマネージャが制御するが(後述)、ほとん どの X プログラムはコマンド行の引き数に -geometry WIDTHxHEIGHT+XOFF+YOFFの形式で (ここで WIDTH, HEIGHT, XOFF, と YOFF は数値) を与えることができ、このアプリケーションのメインウィンドウの望ましい大 きさと位置を指定することができる。

座標指定の WIDTH と HEIGHT の単位はピクセル数か文字数のど ちらかであるが、これはアプリケーションによって異なる。 XOFF と YOFF の単位はピクセルであり、スクリーンの左端か右 端の上端か下端からの間隔をウィンドウにそれぞれ指定する。どちらのタイプ のオフセットも、スクリーンの指定された端から ウィンドウの対応する端ま での距離を指定する。X 軸方向のオフセットは次の方法で指定する。:

+XOFF
    ウィンドウの左端をスクリーンの左端から XOFF ピクセルの所に配置 する(つまり、ウィンドウの原点の X 座標は XOFF になる)。

-XOFF
    ウィンドウの右端をスクリーンの右端から XOFF ピクセルの所に配置 する。XOFF は負の値でもよく、この場合にはウィンドウの右端がスク リーンの外になる。

Y オフセットも同様な意味があり、:

+YOFF
    ウィンドウの上端をスクリーンの上端から YOFF ピクセルの所に配置 する(つまり、ウィンドウの原点の Y 座標は YOFF となる)。 YOFF は負の値でもよく、この場合にはウィンドウの上端がスクリーン の外になる。

-YOFF
    ウィンドウの下端をスクリーンの下端から YOFF ピクセルの所に配置 する。YOFF が負の値でもよく、この場合にはウィンドウの下端がスク リーンの外になる。

オフセットは数値の組として与える必要がある。つまり、XOFF と YOFF の両方を指定する必要がある。ウィンドウを画面のスクリーンの 四隅に位置づけるには次のようにする。:

+0+0
    は左上隅になる。

-0+0
    は右上隅になる。

-0-0
    は右下隅になる。

+0-0
    は左下隅になる。

次の例は、端末エミュレータを大体画面の中央に配置し、ロードアベレージモ ニタとメールボックス、時計を右上隅に配置する。

    xterm -fn 6x10 -geometry 80x24+30+200 &
    xclock -geometry 48x48-0+0 &
    xload -geometry 48x48-96+0 &
    xbiff -geometry 48x48-48+0 &

ウィンドウマネージャ
スクリーン上のウィンドウのレイアウトは ウィンドウマネージャ と呼ばれる 特別なプログラムによって制御される。多くのウィンドウマネージャは与えら れた座標設定値を受けつけるが、座標を無視するものもある(例えば、ポイン タでドラッグしてウィンドウ領域のスクリーン上の位置を明示的に指定させる)。

ウィンドウマネージャは(たとえ複雑でも)通常のクライアントプログラムなの で、色々なユーザインターフェースを構築できる。X コンソーシアムはウィ ンドウの重なり、ポップアップメニュー、ポインタクリックまたはクリックキー 入力モデル、タイトルバー、かっこいいアイコン(アイコンウィンドウを切り 放したくない場合はアイコンマネージャ) をサポートした twm という 名前のウィンドウマネージャを配布している。

他の有名なウィンドウマネージャについては、X コンソーシアムの配布に含ま れるユーザ寄贈のソフトウェアを参照すること。

フォント名
X でテキストとシンボルを表示するための文字集合は、フォント とし て知られている。 典型的にフォントは一般的な見た目と様子を両方披露するイメージを含んでい る。(例えば、 1 つの大きさ、太さ、スラントと文字集合)。 同様に、共通のタイプフェースを基にしているフォントの集合(このバリエー ションは通常 roman, bold, italic, bold italic oblique, bold oblique と 呼ばれる)は ファミリ と呼ばれる。

フォントには色々な大きさのものがある。X サーバは スケーラブル フォントをサポートしている。これは 1 つのソースから任意の大きさのフォ ントを作成できるフォントのことである。サーバは アウトライン フォ ントと ビットマップ フォントのスケーリングをサポートしている。ア ウトラインフォントからのスケーリングは通常ビットマップフォントからのス ケーリングよりかなり良い結果となる。

X サーバはファイルシステムの個々のディレクトリに格納されたファイル、1 つ以上のフォントサーバまたはディレクトリとフォントサーバの両方からフォ ントを得ることができる。 フォントを探すときに X サーバが調べる場所のリストは、フォントパス で制御される。しかし、普通にX をインストールした場合には、X サーバ は共通に使われるフォントディレクトリをフォントパス内に持った状態で起動 するようになっている。フォントパスはいつでも xset プログラムで変 更できる。しかしながら、ディレクトリ名はX サーバのマシンのもので あってアプリケーションのマシンのものではない点には注意すること。

ビットマップフォントファイルは、通常テキストでフォント記述されている bdftopcf をバイナリ形式へコンパイルして作成する。 フォントデータベースは、ソースまたはコンパイルされたフォントがあるディ レクトリで mkfontdir プログラムを実行して作成する。 フォントを追加したときは、サーバが新しいフォントを見つけられるように、 必ず mkfontdir を再実行しなければならない。サーバにフォントデー タベースを再読み込みさせるには、xset プログラムでフォントパスを 設定し直すこと。 例えば、個人のディレクトリにフォントを追加した場合は次のコマンドを使用 する。:

    % cp newfont.pcf ~/myfonts
    % mkfontdir ~/myfonts
    % xset fp rehash

xfontsel と xlsfonts プログラムを使って、サーバで使用でき るフォントを見ることができる。 フォント名はフォントを独自に特定できる個々の情報をすべて含むので、長く なってしまう傾向がある。しかし、X サーバはフォント名のワイルドカード記 述をサポートしているので、次のような

    -adobe-courier-medium-r-normal--10-100-75-75-m-60-iso8859-1

完全なフォント名は は

    -*-courier-medium-r-normal--*-100-*-*-*-*-iso8859-1
のように省略できる。

シェルにおいては * と ? は特別な意味を持っているので、ワイ ルドカードを使ったフォント名は次のようにクォートしなければならない。:

    % xlsfonts -fn '-*-courier-medium-r-normal--*-100-*-*-*-*-*-*'

xlsfonts プログラムを使って、与えられたパターンと一致するフォン トすべてをリストすることができる。引き数がない場合は利用可能なすべての フォントをリストする。このプログラムは通常色々なサイズの同じフォントを リストする。基本となるスケーラブルフォントだけを見るには次のパターンを 使用すること。:

    -*-*-*-*-*-*-0-0-0-0-*-0-*-*
    -*-*-*-*-*-*-0-0-75-75-*-0-*-*
    -*-*-*-*-*-*-0-0-100-100-*-0-*-*

得られた名前の1つを指定したサイズのフォントに変換するには、最初の 2 つ のゼロのどちらかをゼロではない値に置き換える。 最初のゼロを含んでいる項目はピクセル単位での大きさである。特定のフォン トを指定するには、このゼロを指定する高さ(ピクセル単位)に置き換える。 また、二番目のゼロを含む項目はポイントサイズである。これをデシポイント 単位( 722.7 デシポイントは 1 インチになります)のサイズを置き換える。 最後のゼロはピクセルの 10 倍が単位となる、平均的な幅を表すフィールドで ある。サーバによっては、この数値を指定するとスケーリングが歪んでしまう。

フォントサーバ名
TCP 接続で使用するフォントサーバ名を、次に示す形式で指定できる。:

    tcp/hostname:port
    tcp/hostname:port/cataloguelist

hostname はフォントサーバの稼働しているマシンの名称(又は 10 進数の アドレス) で指定する。port は接続用のフォントサーバが接続待ち をしている 10 進数の TCP のポート番号である。cataloguelist はカ タログ名のリストで '+' で区切って指定する。

指定例: tcp/x.org:7100, tcp/198.112.45.11:7100/all

次に示す形式のいずれかで DECnet 接続で使用するフォントサーバ名を指定で きる。:

    decnet/nodename::font$objname
    decnet/nodename::font$objname/cataloguelist

nodename はフォントサーバの稼働しているマシンの名(又は 10 進数の アドレス)で指定する。objname は大文字と小文字の区別がある DECnet の通常のオブジェクト名である。cataloguelist ははカタログ名のリス トで '+' で区切って指定する。

指定例: DECnet/SRVNOD::FONT$DEFAULT, decnet/44.70::font$special/symbols

色名称
ほとんどのアプリケーションには、表示するテキストやグラフィックスの各種 要素の色を指定する方法(リソースやコマンドラインの引き数を使う)がある。 色は絶対色名称かまたは数値による色指定により指定する。数値による色指定 はデバイス依存(RGB)またはデバイス非依存の項目で識別することができる。 色名称文字列では大文字と小文字の区別はない。

X は例えば "red", "blue" 等の絶対色名称を使うことをサポートしている。 この絶対色名称は 1 つ以上の色データベースを検索して得ることができる。 Xlib はまずゼロ個以上のクライアント側のデータベースを検索する。 これらのデータベースの個数、場所と内容は実装依存である。 名称が見つかったら、色は X サーバのデータベースから検索される。 このテキスト形式のデータベースは一般に <XRoot>/lib/X11/rgb.txt ファイルに格納されている。ここで、<XRoot> は X11 をインストールしたディ レクトリのルートに置き換えること。

数値による色指定は色空間名称と次の書式の数値の組で構成される。:

    <color_space_name>:<value>/.../<value>

RGB デバイス指定はプレフィックス "rgb:" によって他と区別し、次の形式で 指定する。:

    rgb:<red>/<green>/<blue>
        <red>, <green>, <blue> := h | hh |
hhh | hhhh
        h := 一桁の 16 進数
h は 4 ビットの値で、 hh は 8 ビットの値、 hhh は 12 ビットの値、 hhhh は 16 ビットの値をそれぞれ表す。 これらの数値は直接 X サーバに渡され、ガンマ補正に使用される。

8 つの基本色は次のように表す。:

    black	rgb:0/0/0
    red	rgb:ffff/0/0
    green	rgb:0/ffff/0
    blue	rgb:0/0/ffff
    yellow	rgb:ffff/ffff/0
    magenta	rgb:ffff/0/ffff
    cyan	rgb:0/ffff/ffff
    white	rgb:ffff/ffff/ffff
互換性のために RGB デバイス用の古い書式はサポートされているが、 これを使い続けることは勧められない。 書式は最初のシャープ記号(#)の後に数値指定が続くものであり、以下のいず れかのフォーマットになる。

    #RGB	(それぞれ 4 ビット)
    #RRGGBB	(それぞれ 8 ビット)
    #RRRGGGBBB	(それぞれ 12 ビット)
    #RRRRGGGGBBBB	(それぞれ 16 ビット)

R, G と B は一桁の 16 進数を表す。 それぞれに 16 ビットより小さい値が指定されている場合、これは値の最上位 のビットを表す(数値がスケーリングされる "rgb:" 形式とは異なる)。 例えば、#3a7 は #3000a0007000 と同じである。

RGB による強度指定はプレフィックス "rgbi:" で識別され、次の書式で指定 される。:

    rgbi:<red>/<green>/<blue>

red, green, と blue は浮動小数点で 0.0 から 1.0 の範囲である。 1.0 が最大の強度で 0.5 が半分の強度のように線形の強度を表す。 この値は X サーバに送る前の Xlib によってガンマ補正が行われる。 これらの値の入力書式は、省略可能な符号、数値を示す文字列(小数点を含む こともある)、省略可能なべき乗フィールド(E 又は e の後ろに符号付き整数 を続けたもの)である。

標準のデバイス依存の文字列による指定は次の書式である。:

    CIEXYZ:<X>/<Y>/<Z>	(none, 1, none)
    CIEuvY:<u>/<v>/<Y>	(~.6, ~.6, 1)
    CIExyY:<x>/<y>/<Y>	(~.75, ~.85, 1)
    CIELab:<L>/<a>/<b>	(100, none, none)
    CIELuv:<L>/<u>/<v>	(100, none, none)
    TekHVC:<H>/<V>/<C>	(360, 100, 100)

全ての値 (C, H, V, X, Y, Z, a, b, u, v, y, x) は浮動少数点の値である。 この数値の幾つかはゼロから上限値の制限があり、上限値は上記では括弧で 括られている。これらの数値の書式は、省略可能な '+' か '-' 符号、小数点 を含むことがある数値を表す文字列、省略可能な指数フィールド(E 又は e の 後ろに省略可能な符号と数値を表す文字列を続けたもの)である。

デバイス依存色についての詳細情報は Xlib リファレンスマニュアル を参照すること。 【訳注：Xlib のオンライマニュアルは各関数毎に別れており、"Xlib" という マニュアルは存在しない。紙で提供されているものを参照するか、 xman を使ってオンラインマニュアルを探すと良いだろう。XQueryColor の オンライマニュアルも参考になると思われる。】

キーボード

X キーボードモデルは 2 層に別れている。これは、(keycode と呼ばれている) 物理的なキーに代表されるサーバ独自のコードと、 (keysym と呼ばれている) キー上に見える文字とか言葉に代表される サーバに依存しないシンボルである。keycode から keysym へ変換する 2 つの テーブルはサーバ内に格納されている。:

修飾キーリスト
    (Shift, Control, と Caps Lock のような) いくつかのキーはモディファイ ア として知られていて、1 つのキーに付属させて、色々なシンボルの選択 をする時に (Shift-a は大文字の A 、Control-l は制御文字 ^L のように) 用いる。サーバは色々なモディファイアの組み合わせに対応するキーコードの リストを保持している。キーを押したり離したりする度に、サーバはどのモディ ファイアが正しく押されているか指定するマスクおよび指示するキーのキーコー ドを含む イベント(event) を生成する。 ほとんどのサーバは、このリストに最初からキーボード上の色々な shift, control, shift lock キーを含まれるように設定をする。

キーマップテーブル
    アプリケーションはキーシンボルテーブルを使って、イベントキーコードとモ ディファイアマスクをキーシンボルに変換する。キーシンボルテーブルは、キー シンボルのそれぞれに対して 1 行、モディファイアの各種状態に対して1列を 持っている表である。このテーブルは通常のタイプライタのしきたりと一致す るようにサーバが最初に初期化する。テーブルが解釈されてキーシンボルにな る正確なセマンティクスは 特定のプログラム、ライブラリと言語入力メソッ ドに依存するが、次のそれぞれの行の最初の 4 つのキーシンボルというしき たりが一般的に受け入れられている。:

リストの最初の 4 つの要素は 2 つのキーシンボルのグループに分けられる。 グループ 1 は 1 番目と 2 番目のキーシンボルで、 グループ 2 は 3 番目と 4 番目のキーシンボルである。 それぞれのグループでは、 1 番目の要素はアルファベットで、2 番目の要素は特別なキーシンボル NoSymbol であり、そしてグループは 1 番目の要素は小文字で、2 番目 の要素は大文字になるグループと同様に扱われる。

グループを切り替えるには MODE SWITCH という名前のキーシンボルにより、 このキーシンボルを何かのキーに割り当て、そのキーを Mod1 から Mod5 のど れかのモディファイアに割り当てることによって制御される。 このモディファイアは ``グループモディファイア'' と呼ばれる。グループ 1 はグループモディファイアが無いときに使用され、グループ 2 はグループモ ディファイアがあるときに使用される。

グループでは、モディファイアの状態によりどのキーシンボルが使用されてい るかがわかる。 1 番目のキーシンボルは Shift と Lock モディファイアがオンになってない 時に使用する。 2 番目のキーシンボルは Shift モディファイアがオンの時、 Lock モディファ イアがオンで 2 番目のキーシンボルが大文字のアルファベットである時、ま たは Lock 修飾キーがオンで ShiftLock として解釈されている時に使われる。 他に、Lock 修飾キーがオンでかつ CapsLock として解釈されている場合は、 Shift モディファイアの状態は最初にキーシンボルの選択に適用される。しか し、キーシンボルが小文字のアルファベットならば、対応する大文字の keysym が代わりに使用される。

オプション
ほとんどの X プログラムでは、同じ名前のコマンドラインオプションと引き 数を使用できる。X ツールキットイントリンシクスを使って書かれた全てのア プリケーションは自動的に次のオプションを処理することができる。

-display display
    このオプションは使用する X サーバの名前を指定する。

-geometry geometry
    このオプションはアプリケーション起動時のウィンドウのサイズと位置を指定 する。

-bg color, -background color
    どちらのオプションもウィンドウの背景色を指定する。

-bd color, -bordercolor color
    どちらのオプションもウィンドウの枠の色を指定する。

-bw number, -borderwidth number
    どちらのオプションもウィンドウの枠の幅をピクセル数で指定する。

-fg color, -foreground color
    どちらのオプションもテキストで使用する色を指定する。

-fn font, -font font
    どちらのオプションもテキストを表示するフォントを指定する。

-iconic
    このオプションを指定すると、アプリケーションのウィンドウの起動時の状態 が可視状態ではなく、ユーザがウィンドウを即座にアイコン化したような状態 となる。ウィンドウマネージャは、アプリケーションの要求を優先しないかも しれない。

-name
    このオプションはアプリケーションが見つけるリソースの名前を指定する。 このオプションは、同じアプリケーションを区別して実行するためにシェルの エイリアスで使うと便利である。この際には、実行可能ファイル名を変えるた めにリンクを作る必要はない。

-rv, -reverse
    どちらのオプションも、可能であればプログラムを反転表示をシミュレートす る。これは、しばしば背景色と前景色を入れ替えることで実現される。全ての プログラムでこうなるわけではなく、正しく実装しているわけでもない。この オプションが便利なのは通常、白黒表示をしている場合だけである。

+rv
    このオプションを指定すると、反転表示のシミュレートを行わない。 このオプションは反転表示が必ず失敗する場合にデフォルト値を上書きする際 に使う。

-selectionTimeout
    このオプションは通信する 2 つのアプリケーションがセレクション要求に応 答しなければならないタイムアウト時間をミリ秒単位で指定する。

-synchronous
    このオプションは X サーバへのリクエストが非同期ではなく同期的に送られ ることを指定する。 Xlib は通常サーバへの要求をバッファに蓄積し、エラーが起きても必ずしもすぐに は報告されない。このオプションはアプリケーションのデバッグするときにバッ ファリングを無効にできる。正しく動作しているプログラムに使用してはなら ない。

-title string
    このオプションはこのウィンドウに用いるタイトルを指定する。この情報は 時々ウィンドウマネージャによって使用され、ウィンドウを区別するような 見出しの類に使われる。

-xnllanguage language[_territory][.codeset]
    このオプションはリソースの解決と他のファイル名に使用する言語、地域と コードセットを指定する。

-xrm resourcestring
    このオプションはいくつかのデフォルトを上書きするリソース名と値を指定す る。これはコマンドライン引き数では明示的に指定できないようなリソースを 設定する際に役立つ。

リソース
アプリケーションの仕上げを簡単に個人の好みに合わせられるようにするため、 X はプログラムリソース(背景、ウィンドウのタイトル等)のデフォルト値を格 納するための機構を持っている。リソースはアプリケーションが実行されたと きに色々な場所から読み込まれる。プログラムコンポーネントは階層的に指定 され、この階層中の各ノードはクラス名とインスタンス名で指定される。 アプリケーションのトップレベルのクラス名とインスタンス名はアプリケーショ ン自身の名称である。慣習として、アプリケーションのクラス名はプログラム 名と同じであるが、頭文字は大文字にされる(例えば、Bitmap または Emacs)。ただし、``x'' で始まるいくつかのプログラムについても、 歴史的な理由から 2 文字目が大文字にされる。

リソースの正確な文法を示す:

ResourceLine	=	Comment | IncludeFile | ResourceSpec | <empty line>
Comment	=	"!" {<NULL 文字と改行以外の任意の文字>}
IncludeFile	=	"#" WhiteSpace "include" WhiteSpace FileName WhiteSpace
FileName	=	<OS で有効なファイル名>
ResourceSpec	=	WhiteSpace ResourceName WhiteSpace ":" WhiteSpace Value
ResourceName	=	[Binding] {Component Binding} ComponentName
Binding	=	"." | "*"
WhiteSpace	=	{<空白文字> | <水平タブ文字>}
Component	=	"?" | ComponentName
ComponentName	=	NameChar {NameChar}
NameChar	=	"a"-"z" | "A"-"Z" | "0"-"9" | "_" | "-"
Value	=	{<NULL 文字とエスケープされていない改行文字を以外の任意の文字>}

縦棒 (|) で区切られた要素は選択肢である。 中括弧 ({...}) は囲んだ要素のゼロ回以上の繰り返しを表す。 大括弧 ([...]) は囲んだ要素が省略可能であることを表す。 引用符 ("...") は文字列を囲むために使われる。

IncludeFile 行は指定したファイルの内容でその行を置き換えるように解釈さ れる。"include" という語は小文字でなければならない。 ファイル名はその行が現れたファイルがあるディレクトリから相対的に解釈さ れる(例えば、ファイル名がディレクトリも相対ディレクトリの指定も含まな い場合)。

ResourceName は 2 つかそれ以上の結合文字での連続したシーケンスを含む。 このシーケンスが"." 文字だけを含む場合には 1 つの "." 文字で置き換 えられ、そうでない場合には 1 つの "*" 文字で置き換えられる。

リソースデータベースは与えられた ResourceName に対して複数のエントリー を持つことはない。リソースファイルが同じ ResourceName に対して複数の行 を持つ場合は、ファイルに最後に現れた行が使用される。

ResourceSpec 内の名前やコロンの前後の空白文字は無視される。 Value を空白文字で始められるようにするため、2 文字のシーケンス ``\space'' (バックスラッシュに続く空白)が識別されて、空白文字 に置き換えられ、2 文字のシーケンス ``\tab'' (バックスラッシュ に続く水平タブ)は認識されて水平タブに置き換えられる。 Value に改行文字を含められるようにするため、2 文字のシーケンス ``\n'' が認識され、改行文字を置き換えられる。 Value がテキストファイル内で複数行で分割して記述できるように、2 文字の シーケンス ``\newline''(バックスラッシュに続く newline)が認識 され、これは値から削除される。 Value に任意の文字を含められるようにするため、4 文字のシーケンス ``\nnn''が認識され、シーケンスで指定された8進値を持つ1つのバ イト値に置き換えられる。 ここで、それぞれの n は ``0''-``7'' の範囲の値をとる。 最後に、2 文字のシーケンス ``\\'' が認識され、1 つのバックスラッシュ で置き換えられる。

アプリケーションがリソースの値を探すときには、クラス名とインスタンス名 の両方を使って階層構造の完全パスが指定される。 しかし、リソース値は通常、パターンマッチング構造を用いて部分的にだけ指 定された名前とクラスが与えられる。 アスタリスク(*)は緩い結合であり、間に任意の数の要素が入っていること を表す。これには何もないことも含まれる。 ピリオド (.) は強い結合であり、隣接する要素を区切るために使われる。 疑問符(?)は任意の 1 つの要素名またはクラスと一致する。 データベースの項目は緩い結合では終了できず、最後の要素("?" は許されな い)は指定しなければならない。 検索アルゴリズムは、問い合わせられた完全な名前とクラスに対して最も近く (最も指定に近く)マッチするエントリーをリソースデータベースから検索する。 複数のエントリーが完全な名前とクラスにマッチするときには、1つだけを選 ぶために優先順位の規則が使われる。

完全な名前とクラスは 1 回に1つのコンポーネントが左から右へ(最も高いな 階層から低いの階層へと)走査される。 それぞれのレベルでは、対応する要素かつ/またはマッチするそれぞれのエン トリーの結合が決定され、これらの一致した要素と一致したエントリーが優先 順位規則によって比較される。 ルールが 1 つの項目をほかの項目から選択するまで、次のレベルに移動する 前にそれぞれのルールがそれぞれのレベルで適応される。規則(優先順位)を以 下に示す:

1.  マッチする要素を含むエントリー(名前、クラス、"?"のいずれか)は、 レベルを省略したエントリー(つまり、緩い結合でレベルとマッチするエント リー)より優先順位が高い。

2.  名前がマッチするエントリーは、クラスとマッチするエントリーと "?" を使 用してマッチするエントリーのどちらよりも優先順位が高い。 クラスがマッチするエントリーは "?" を使用してマッチするエントリーより も優先順位が高い。

3.  強い結合が前にあるエントリーは、緩い結合が前にあるエントリーよりも優先 順位が高い。

X ツールキットイントリンシクスに基づくプログラムは、次のソースからリソー スを得る(他のプログラムは通常これらのソースの一部をサポートしている)。

RESOURCE_MANAGER root window property
    全てのマシンのクライアントで使用可能なグローバルリソースは、xrdb プログラムを使用用いて最初のスクリーンのルートウィンドウ上の RESOURCE_MANAGER プロパティに格納する。

SCREEN_RESOURCES root window property
    全てのマシンのクライアントで使用可能であり、与えられたスクリーンに固有 のリソース(色など)は、そのスクリーンのルートウィンドウ上の SCREEN_RESOURCES プロパティに格納される。 xrdb プログラムは自動的にリソースをソートしてリソースを RESOURCE_MANAGER と SCREEN_RESOURCES の適切な方に置く。

application-specific files
    アプリケーション固有のリソースについては、XUSERFILESEARCHPATH 環境変数 または XAPPLRESDIR 環境変数によって指定されたディレクトリ(これは 1 つ のディレクトリを指し、POSIX システムでは1つのディレクトリと '/' で終わ る)と標準の位置にあるディレクトリ(通常は <XRoot>/lib/X11/ 以下にあるが、これはXFILESEARCHPATH 環境変数で上書きできる)が検索され る。 例えば、アプリケーションのデフォルトのリソースは <XRoot>/lib/X11/app-defaults/ に置かれる。 詳しくは X ツールキットイントリンシクス - C 言語インタフェース のマニュアルを参照すること。

XENVIRONMENT
    全てのユーザ固有とマシンに特有なリソースは、XENVIRONMENT 環境変数の設定に 全てのアプリケーションが読み込むリソースファイルの名前をセットすること によって指定することができる。この環境変数が定義されていないときは、代 わりに $HOME/.Xdefaults-hostname という名前のファイルが参 照される。ここで、hostname はアプリケーションが動作しているホス ト名である。

-xrm resourcestring
    リソースはコマンドラインからも指定できる。resourcestring は、1 つのリソース名と先に述べたような値である。文字列が含む文字がシェルに解 釈される場合には(アスタリスク等)、クォートしなければならない点に注意す ること。任意の数の -xrm 引き数をコマンドラインで指定することが できる。

プログラムのリソースはクラス と呼ばれるグループに組織されている ので、個々のリソースの集まり(それぞれを インスタンス と呼ぶ)は一 度にすべて設定できる。伝統的に、リソースのインスタンス名は小文字で始ま り、クラス名は大文字で始まる。 複数の語からなるリソースは、次の語句の 1 文字目を大文字にして語句を連 結させる。X ツールキットイントリンシクスを使って書かれたプログラムは最 低、次のリソースを持つ。:

background (class Background)
    このリソースはウィンドウの背景に使用する色を指定する。

borderWidth (class BorderWidth)
    このリソースはウィンドウ枠の幅をピクセル数で指定する。

borderColor (class BorderColor)
    このリソースはウィンドウ枠に使用する色を指定する。

X ツールキットイントリンシクスを使って書かれたプログラムは foreground リソース(Foreground クラス)も持つ。これは、ウィ ンドウ内のテキストやグラフィックスで使用するカラーを指定する。

クラスとインタンスの指定を組み合わせることにより、アプリケーションの好み は早く、簡単に設定できる。カラーディスプレイのユーザは、Background と Foreground クラスに特定のデフォルト値を設定したくなることが多いだろう。 その後で、テキストカーソルのような特定の色のインスタンスを、すべての関 係するリソースを定義することなく上書きできる。以下に設定例を示す。:

    bitmap*Dashed:  off
    XTerm*cursorColor:  gold
    XTerm*multiScroll:  on
    XTerm*jumpScroll:  on
    XTerm*reverseWrap:  on
    XTerm*curses:  on
    XTerm*Font:  6x10
    XTerm*scrollBar: on
    XTerm*scrollbar*thickness: 5
    XTerm*multiClickTime: 500
    XTerm*charClass:  33:48,37:48,45-47:48,64:48
    XTerm*cutNewline: off
    XTerm*cutToBeginningOfLine: off
    XTerm*titeInhibit:  on
    XTerm*ttyModes:  intr ^c erase ^? kill ^u
    XLoad*Background: gold
    XLoad*Foreground: red
    XLoad*highlight: black
    XLoad*borderWidth: 0
    emacs*Geometry:  80x65-0-0
    emacs*Background:  rgb:5b/76/86
    emacs*Foreground:  white
    emacs*Cursor:  white
    emacs*BorderColor:  white
    emacs*Font:  6x10
    xmag*geometry: -0-0
    xmag*borderColor:  white

これらのリソースはホームディレクトリの .Xresources と呼ばれるファ イルに格納されている場合は、次のコマンドでこれらをサーバ内に存在するリ ソースに追加できる。:

    % xrdb -merge $HOME/.Xresources

これは、取り扱いが簡単な開始時のスクリプトにおいてユーザの指定したデフォ ルト値をサイト全体で使っているデフォルト値とマージするためによく使われ ている方法である。どのようなサイトでも、リソースをロードする便利な方法 を用意しておくとよい。詳細な情報については、Xlib のマニュアルの Resource Manager Functions のセクションを参照すること。

例
以下は、よく使われるコマンドの一部のコマンドラインのサンプルを集めたも のである。それぞれのコマンドに関する詳しい情報については、そのコマンド のオンラインマニュアルを参照すること。

    %  xrdb $HOME/.Xresources
    %  xmodmap -e "keysym BackSpace = Delete"
    %  mkfontdir /usr/local/lib/X11/otherfonts
    %  xset fp+ /usr/local/lib/X11/otherfonts
    %  xmodmap $HOME/.keymap.km
    %  xsetroot -solid 'rgbi:.8/.8/.8'
    %  xset b 100 400 c 50 s 1800 r on
    %  xset q
    %  twm
    %  xmag
    %  xclock -geometry 48x48-0+0 -bg blue -fg white
    %  xeyes -geometry 48x48-48+0
    %  xbiff -update 20
    %  xlsfonts '*helvetica*'
    %  xwininfo -root
    %  xdpyinfo -display joesworkstation:0
    %  xhost -joesworkstation
    %  xrefresh
    %  xwd | xwud
    %  bitmap companylogo.bm 32x32
    %  xcalc -bg blue -fg magenta
    %  xterm -geometry 80x66-0-0 -name myxterm $*
    %  xon filesysmachine xload

返り値
様々なプログラムが種々のエラーメッセージを生成する。 Xlib 内の標準のエラーハンドラ(ツールキットアプリケーションの多く も使用している)は、標準リソースを使用してエラー発生時の診断メッセージ を作成する。これらのメッセージのデフォルト値は通常、 <XRoot>/lib/X11/XErrorDB に格納されている。 このファイルが無い場合には、エラーメッセージはかなり簡単でわけのわから ないものになるだろう。

X ツールキットイントリンシクスがリソースの文字列を適切な内部書式に変換 するときにエラーが起こった場合、エラーメッセージは通常出力されない。様々 なディスプレイ(カラーとモノクロ、ファンとが多い場合と少ない場合、等)で 1つのリソースの組み合わせを使いたいときには便利であるが、アプリケーショ ンがうまく動作しない理由を調べるときには問題になるだろう。この挙動は StringConversionsWarning リソースを設定することにより上書きでき る。

X ツールキットイントリンシクスが常に文字列変換のエラーを出力するように 強制するには、xrdb プログラムが使用する RESOURCE_MANAGER プロパ ティ上にロードするファイル(ユーザのホームディレクトリにある .Xresources か .Xres であることが多い)に次のリソースを加え ること。:

    *StringConversionWarnings: on

文字列変換のメッセージはただ特別なアプリケーション用に出力するには、 適切なインスタンス名をアスタリスクの前につける。:

    xterm*StringConversionWarnings: on

関連項目

XConsortium(1), XStandards(1), Xsecurity(1), appres(1), bdftopcf(1), bitmap(1), editres(1), fsinfo(1), fslsfonts(1), fstobdf(1), iceauth(1), imake(1), lbxproxy(1), makedepend(1), mkfontdir(1), oclock(1), proxymngr(1), rgb(1), resize(1), rstart(1), smproxy(1), twm(1), x11perf(1), x11perfcomp(1), xauth(1), xclipboard(1), xclock(1), xcmsdb(1), xconsole(1), xdm(1), xdpyinfo(1), xfd(1), xfindproxy(1), xfs(1), xfwp(1), xhost(1), xieperf(1), xinit(1), xkbbell(1), xkbcomp(1), xbkevd(1), xkbprint(1), xkbvleds(1), xkbwatch(1), xkill(1), xlogo(1), xlsatoms(1), xlsclients(1), xlsfonts(1), xmag(1), xmh(1), xmodmap(1), xon(1), xprop(1), xrdb(1), xrefresh(1), xrx(1), xset(1), xsetroot(1), xsm(1), xstdcmap(1), xterm(1), xwd(1), xwininfo(1), xwud(1). Xserver(1), Xdec(1), XmacII(1), Xsun(1), Xnest(1), Xvfb(1), XF86_Acc(1), XF86_Mono(1), XF86_SVGA(1), XF86_VGA16(1), XFree86(1), kbd_mode(1), Xlib - C Language X Interface, and X Toolkit Intrinsics - C Language Interface

登録商標

X Window System は X Consortium, Inc. の登録商標である。

著者

非常にたくさんの著者がいる。リリース 6.3 の配布物は X Consortium, Inc. が配布している。ここに挙げるべき全ての人々の名前は 個々のドキュメントやソースファイルの中にある。このリリースに関わった X Consortium に在籍するスタッフは: Donna Converse (名誉メンバ), Stephen Gildea (名誉メンバ), Kaleb Keithley, Matt Landau (名誉メンバ), Ralph Mor (名誉メンバ), Janet O'Halloran, Bob Scheifler, Ralph Swick, Dave Wiggins (名誉メンバ), そして Reed Augliere である。

X ウィンドウシステムの基本部分は、元々マサチューセッツ工科大学 (Massachusetts Institute of Technology)のコンピュータ科学研究所 (Laboratory for Computer Science)が開発し、その全ての権利は X コンソー シアムに 1994/01/01 付けで譲渡された。 X Consortium, Inc. は 1996/12/31 付けで解散した。X ウィンドウシステム に関する全ての権利は Open Software Foundation へ譲渡された。