X(1)

名称
X - 移植可能な, ネットワーク透過なウィンドウシステム

文法

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

X Consortium はこのソフトウェアに言及する時は次の名称を使用することを 要求します。:

X
X Window System
X Version 11
X Window System, Version 11
X11

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

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

X はオーバラップする階層構造のサブウィンドウとテキストとグラフィック操作 を白黒でもカラーのディスプレイでサポートしています。 利用可能な関数の正式な説明は Xlib - C Language X Interface マニュアル、 X Window System Protocol 仕様書、 X Toolkit Intrinsics - C Language Interface マニュアルと 種々のツールの文書を参照してください。

X を使用するプログラムの数はかなり多いです。 X Consortium 配布物の核として提供しているプログラムは次のものです。: ターミナルエミュレータ、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 P, fstobdf; X Image Extension 実行プログラム, xieperf; mkfontdir; ディスプレイサーバと関連ユーティリティ、Xserver, rgb, mkfontd ir; リモート実行ユーティリティ、 rstart と xon; クリップボードマネージャ、 xclipboard; xkbwatch; キーボード構成記述コンパイラと関連ユーティリティ、 xkbcomp, xkbprint, xkbbell, xkbevd, xkbvleds, と xkbwatch; クライアント停止ユーティリティ、 xkill; 最適化 X プロトコルプロキシ、 lbxproxy; ファイアウォールセキュリティプロキシ、 xfwp; プロキシを制御するプロキシマネージャ、 proxymngr; プロキシを発見するユーティリティ、 xfindproxy; Netscape Navigator Plug-ins, libxrx.so と libxrxnest.so; RX MIME-タイプ ヘルパープログラム、 xrx; とスクリーンの全て若しくは一部を再描画するユーティリティ、 xrefresh 。

その他の多くのユーティリティ、ウィンドウマネージャ、ゲーム、ツールキット、 その他は X Consortium 配布物のユーザによる寄贈ソフトウェアか インターネット 上の anonymous ftp で利用可能です。 詳細は自サイトの管理者に問い合わせてください。

はじめに

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

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

xinit (シェルから手動で起動した場合)
    複数のウィンドウシステムをサポートしているサイトは X を手動で開始する xinit の使用を選択しましょう。お手元のマシンがそうだったら、自サイト の管理者に "x11", "startx", とか "xstart" のような (標準リソース のロード、ウィンドウマネージャの起動、クロックの表示、端末エミュレータの 起動を行うような) サイト独自の初期化作業をやってもらいましょう。 さもなければ、このようなスクリプトを xinit プログラムを使って構築し ましょう。このユーティリティは単にユーザの指定したプログラムをサーバが 起動するときに実行し、ほかに使いたいクライアントを起動してそれが終わるのを 待っています。ユーザの指定したプログラムのそれぞれ若しくは全てがシェル スクリプトならば、かっこいいインタフェースにする為の相当な柔軟性があります。 したがって、xinit はエンドユーザ用には向いていません。

ディスプレイ名称

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

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

この情報はサーバに接続したいアプリケーションがどのように認識するかとどの スクリーンを標準で使うか (複数のモニタに表示するとき) に使用されます。

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

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

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

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

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

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

back 最後に、ほとんどの X プログラムは一時的に DISPLAY の内容を上書きする -display displayname のコマンド行オプションを受け付けます。 これはほとんどの一般的に他の人のスクリーン若しくは "remote shell" コマンド の部分にディスプレイに xterm が戻ってくるように使用されます。例えば、

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

のようにします。 X サーバは様々な異なる接続チャネル (ネットワークバイトストリーム、共有メモリ 等) との接続を listen します。与えられたサーバに接続する 1 つ以上の接続方法 があるので、ディスプレイ名称の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 サーバはいくつかのアクセス制御の種類を使用できます。リリース 6 の提供する 機構は:
    Host Access	単純なホストベースのアクセス制御。
    MIT-MAGIC-COOKIE-1	共有された平文の "cookies"。
    XDM-AUTHORIZATION-1	安全な DES ベースの秘密鍵。
    SUN-DES-1	Sun の安全な rpc システムベース。
    MIT-KERBEROS-5	Kerberos バージョン 5 user-to-user。

performs any xdm はサーバとユーザがアクセスできるファイルに認証情報を置くために アクセス制御を初期化します。通常、常時接続を受けるホストのリストは空にして おき、明白に認証されたクライアントだけがディスプレイに接続できます。 ホストのリストに (xhost で) 項目を追加したときは、サーバはそれらの マシンからの接続についての認証は実行されません。xhost の実行は注意しましょう。

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

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

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

application. from the 座標指定の WIDTH と HEIGHT の部分は通常アプリケーションに よってピクセル数又は文字数のどちらかで測定します。 XOFF と YOFF の部分はピクセルで測定してスクリーンの左端か右端の 上端か下端からの間隔をウィンドウにそれぞれ指定します。両方のオフセットの種類は スクリーンの端からウィンドウの対応する端までを測定します。X のオフセットは 次の方法で指定します。:

+XOFF
    will be left edge ウィンドウの左端をスクリーンの左端からの XOFF ピクセルの所に位置づけま す (つまり、ウィンドウの原点の X 座標は XOFF で指定します)。

-XOFF
    ウィンドウの右端をスクリーンの右端からの XOFF ピクセルの所に位置づけま ます。ウィンドウの右端がスクリーンから外れたとき XOFF が負の値になります。

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

+YOFF
    edge ウィンドウの上端をスクリーンの上端からの YOFF ピクセルの所に位置づけま ます (つまり、ウィンドウの原点の Y 座標は YOFF で指定します)。 ウィンドウの上端がスクリーンから外れたとき YOFF が負の値になります。

-YOFF
    ウィンドウの下端をスクリーンの下端からの YOFF ピクセルの所に位置づけま ます。ウィンドウの上の下端がスクリーンから外れたとき YOFF が負の値に なります。

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

+0+0
    は左上隅になります。

-0+0
    は右上隅になります。

-0-0
    は右下隅になります。

+0-0
    は左下隅になります。

次の例は、端末エミュレータを大体画面の中央に位置づけ、負荷平均モニタと mailbox, clock を右上隅に位置づけます。

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

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

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

他の有名なウィンドウマネージャ用に X Consortium へユーザが寄贈した ソフトウェアを御覧下さい。

フォント名称
italic, X に表示するテキストとシンボル用の収集物は フォント(fonts) として知ら れています。 典型的にフォントは一般的な見た目と様子を両方披露するイメージを含んでいます (例えば、 1 つの大きさ、太さ、スラントとキャラクタセット)。 同様に、一般のタイプフェースを基にしているフォントの収集物 (roman, bold, italic, bold italic oblique と bold oblique と通常呼ばれている変種) は ファミリ(families) と呼ばれています。

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

X サーバはファイルシステムの個々のディレクトリに格納されたファイル又は
 1 つ以上のフォントサーバ若しくはディレクトリとフォントサーバの混合物から フォントを得ることができます。 フォントパス(font path) で制御されたフォントを見つけたいときサーバは場 所のリスト を参照します。しかし、殆んどの導入形態ではフォントパス内のフォントディレクトリ の全てをサーバ開始時に選択します。フォントパスは何時でも xset プログラム で変更できます。しかしながら、ディレクトリ名称は server のマシンのもの であってアプリケーションのマシンのものではないことを心に留めておいてください。

ビットマップフォントファイルは通常テキストでフォント記述されていて 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-*-*

指定したサイズのフォントへ解決した名称に変換するには、最初の 2 つのゼロを ゼロではない値に置き換えてください。 最初のゼロを含んでいる項目はピクセル数での大きさで、サイズにより高さを 置き換えてフォント名称を指定します。 あるいは、二番目のゼロを含む項目はデシポイント数でサイズを置き換えて指定しま す ( 722.7 デシポイントは 1 インチになります) 。 最後のゼロはピクセルの 10 倍数の平均的な幅です。この数値を指定したときは 幾つかのサーバでは漠然としたスケールになります。

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

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

connections. hostname はフォントサーバの稼働しているマシンの名称 (又は 10 進数の アドレス) で指定します。port は接続用のフォントサーバが listen している 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/44.70::font$special/symbols. 例えば: DECnet/SRVNOD::FONT$DEFAULT, decnet/44.70::font$special/sym bols とします。

カラー名称
ほとんどのアプリケーションは表示するテキストやグラフィックスの色々な要素の カラーを仕上げる方法 (リソースやコマンド行の引数を使う) を提供しています。 カラーは絶対カラー名称か若しくは数値によるカラー指定により指定します。 数値によるカラー指定はデバイス依存の (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 によってガンマ補正を行います。 これらの値の入力書式は符号が任意の 10 進数を文字列にして点を含めて指定し、 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) は浮動少数点の値です。 この数値の幾つかはゼロから上限値の制限があり、上限値は上記では括弧で 括られています。これらの数値の書式は任意の '+' か '-' 符号を含み、 10 進数の小数点か E 又は e の後ろに符号付き整数を含めたべき指数でも 指定できます。

デバイス依存カラーについての詳細情報は Xlib リファレンスマニュアル を参照してください。 【訳注：Xlib のオンライマニュアルは各関数毎に別れており、"Xlib" という マニュアルはありません。紙で提供されているものをご覧になるか、 ここの関数を xman 経由で探すと良いでしょう。または XQueryColor の オンライマニュアルが参考になるでしょう。】

キーボード

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

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

キーマップテーブル
    アプリケーションはイベントキーコードと修飾キーマスクから keysym へ それぞれの keycode 対応に 1 行毎、各列に色々な修飾キーの状態からなる keysym テーブル(keysym table) を使用して変換します。このテーブルは通常 のタイプライタの しきたりと一致するようにサーバが最初に初期化します。本当のどのように テーブルが解釈される意味は 特定のプログラム、ライブラリと言語入力 メソッドに依存しますが、次のそれぞれの行の最初の 4 つの keysym が一般的に 支持されているというしきたりによって keysym が作成されています。

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

グループを切り替えるには MODE SWITCH という名称の keysym によって制御され 、この keysym を何かのキーに張り付けて、そのキーを Mod1 から Mod5 のどれか の修飾キーに張り付けることができます。この修飾キーは ``group modifier'' と 呼ばれています。グループ 1 は group modifier が無いときに使用され、 グループ 2 は group modifier があるときに使用されます。

グループでは、修飾キーの状態はどの keysym が使用されているかが分かります。 1 番目の keysym は Shift と Lock 修飾キーがオンになってない時に使用します。 2 番目の keysym は Lock 修飾キーがオンで 2 番目の keysym が大文字の アルファベット若しくは Lock 修飾キーがオンで且つ ShiftLock が解釈されている 場合に Shift 修飾キーがオンの状態時に使用されします。 他に、Lock 修飾キーがオンで且つ CapsLock が解釈されている場合は、 Shift 修飾キーが keysym をまず適応しますが、keysym は小文字のアルファベット になりますが、そのときは対応する大文字の keysym が代わりに使用されます。

オプション
殆んどの X プログラムは 同じ名称のコマンド行オプションと引数を使用できます。 X Toolkit Intrinsics を使って書かれた全てのアプリケーションは自動的に 次のオプションを受け入れる事ができます。

-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 つのアプリケーションが selection 要求での 応答のタイムアウトをミリ秒単位で指定します。

-synchronous
    Xlib reported このオプションは X サーバが非同期の代わりに同期要求を送ることを表しています。 Xlib は通常サーバへの要求をバッファに蓄積し、エラーが起きてもすぐに報告する必要は ありません。このオプションはアプリケーションのデバッグするときにバッファを やめることができます。動作しているプログラムに使用してばいけません。

-title string
    information window. このオプションはこのウィンドウに用いるタイトルを指定します。この情報は 時々ウィンドウマネージャによって使用され、ウィンドウを区別するような 幾つかのヘッダの種類を提供します。

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

-xrm resourcestring
    defaults. It このオプションは幾つかの標準値を上書きするリソース名称と値を指定します。 これは明示的なコマンド行引数にないようなリソースの設定するのに有用です。

リソース
Emacs) ユーザの好みの設定を簡単にアプリケーションの仕上げをするのに、X はプログラム リソース (背景、ウィンドウのタイトル等) の標準値を格納するための機構を 提供します。リソースはアプリケーションが実行しているときに色々な場所から 読み込んだ文字列として指定されます。プログラムコンポーネントはそれぞれの ノードがクラスと実体名称によって階層的に区別できる階層構造をもつ名称です。 アプリケーションのトップレベルのクラスと実体名称はアプリケーション自身の 名称です。慣習として、アプリケーションのクラス名称はプログラム名称と同じで すが、頭文字を大文字に (例えば、Bitmap 又は Emacs) しますが ``x'' で始まるものと 2 文字目が大文字になっている幾つかのプログラムは 歴史的な理由で大文字にはしません。

リソースの正確な文法は:

ResourceLine	=	Comment | IncludeFile | ResourceSpec | <empty line>
Comment	=	"!" {<any character except null or newline>}
IncludeFile	=	"#" WhiteSpace "include" WhiteSpace FileName WhiteSpace
FileName	=	<valid filename for operating system>
ResourceSpec	=	WhiteSpace ResourceName WhiteSpace ":" WhiteSpace Value
ResourceName	=	[Binding] {Component Binding} ComponentName
Binding	=	"." | "*"
WhiteSpace	=	{<space> | <horizontal tab>}
Component	=	"?" | ComponentName
ComponentName	=	NameChar {NameChar}
NameChar	=	"a"-"z" | "A"-"Z" | "0"-"9" | "_" | "-"
Value	=	{<any character except null or unescaped newline>}

縦棒 (|) で区切られた要素は選択肢です。 カールした括弧 ({...}) はゼロか囲んだ要素の繰り返しを表します。 四角い括弧 ([...]) は囲んだ要素は任意であることを表します。 引用符 ("...") はそのままの文字を囲むのに使用します。

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

ResourceName は 2 つかそれ以上の Binding 文字でくっつける連続した列を 含んでいます。列は 1 つの "." 文字で置き換えられ、"." 文字だけの場合は 1 つの "*" 文字で置き換えられます。

リソースデータベースは ResourceName で与えられた 1 つ以上の項目を含みません。 リソースファイルが同じ ResourceName が複数行ある場合、ファイルの最後の行 が使用されます。

ResourceSpec 内の名称やコロンの前や後ろにある空白文字は無視されます。 Value が空白文字ではじめるのを許可するためには、2 文字の列 ``\space'' (バックスラッシュに続く空白)を認め、space を空白で置き換えて、 2 文字の列 ``\tab'' (バックスラッシュに続く水平タブ) を認め 水平 tab の文字を置き換えましょう。 Value が改行文字を含めるのを許可するためには、2 文字の列 ``\n'' を認め、改行文字を置き換えてください。 Value がテキストファイルで複数行に別れた値を許可するためには、2 文字の列 ``\newline'' (バックスラッシュに続く newline) を認め、 値から消してください。 Value が任意の文字を含めるのを許可するためには、4 文字の列 ``\nnn'' それぞれの n は ``0''-``7'' の範囲の桁をとる値で、 これを認めたら、列によって 8 進数の 1 バイトで置き換えましょう。 最後に、2 文字の列 ``\\'' を認めたら、1 つのバックスラッシュで 置き換えましょう。

アプリケーションがリソースの値を探すとき、クラスと実体名称の両方の階層構造 の完全パスを指定します。しかしながら、リソースの値は通常、部分的な指定され た名称とクラスだけ与えられ、パターンマッチング構造を使用して探します。 アスタリスク (*) は結合をなくしてしまうし、介入するコンポーネントの数に 代表されるものを何も含まないで使用します。 ピリオド (.) はきつく結合させ、隣接したコンポーネントを即座に切り放すのに 使用できます。 クェスチョンマーク (?) は 1 つのコンポーネント名称又はクラスと一致させます。 データベースの項目は緩い結合では終了できないのは、最後のコンポーネント ("?" ではできない) を指定しなければならないからです。 lookup アルゴリズムは問い合わせに対して殆んど一致した (殆んど特定できた) 正式の名称とクラス項目のリソースデータベースを探します。 1 つ以上のデータベース項目と正式の名称とクラスが一致した場合は、 先行ルールによって 1 つだけに選別します。

正式な名称とクラスは 1 回に 1 つのコンポーネントが左から右へ (もっとも 高次な階層から低次の階層へ) 走査されます。 それぞれのレベルでは、対応するコンポーネントか又はそれぞれの一致する 決定した項目を結合させ、一致したコンポーネントと一致した項目を 先行ルールによって比較します。次のレベルに移動する前にルールが 1 つの項目 をほかの項目から選択するまで、それぞれのルールはそれぞれのレベルで適応され ます。(手順の) ルールは:

1.  レベルを省略した項目 (それは緩い結合ではレベルと一致する項目) と一致するコンポーネントを含む項目 (名称、クラスか又は "?") を 先行から引き継ぎます。

2.  名称が一致する項目はクラスと一致する項目と "?" を使用して一致した項目の 両方を先行から引き継ぎます。 クラスが一致する項目は "?" を使用して一致した項目を先行から引き継ぎます。

3.  きつい結合による先行した項目は緩い結合により先行した項目を先行から引き継ぎ ます。

X Toolkit Intrinsics を基にしているプログラムは次のソースからリソースを 得ます(ほかのプログラムは通常これらのソースのサブセットをサポートしています)。

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 環境変数によって指定された (POSIX システムでは 1 つのディレクトリと '/' で終わっている) ディレクトリと標準の位置にあるディレクトリ <XRoot>/lib/X11/app-defaults/ です。 詳細は X Toolkit Intrinsics - C Language Interface のマニュアルを ご覧下さい。

XENVIRONMENT
    幾つかのユーザとマシンに特有なリソースは XENVIRONMENT 環境変数の設定に よって全てのアプリケーションがロードするリソースファイルの名称を指定し ます。この環境変数が定義されていないときは、代わりに $HOME/.Xdefaults-hostname という名称のファイルを見にいきます。 ここで、hostname はアプリケーションが存在するホストの名称です。

-xrm resourcestring
    value as コマンド行から指定できるリソースです。リソース文字列(resourcestring) は 1 つのリソース 名称と上記の環境変数です。文字列が含んでいる文字がシェルに解釈されるので
     (例えばアスタリスクは) 引用符で囲われていなければいけないことに注意して ください。-xrm 引数の数値はコマンド行から与えます。

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

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

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

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

X Toolkit Intrinsics を使って書かれたプログラムは 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

your home これらのリソースはホームディレクトリの中に .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

診断
<XRoot>/lib/X11/XErrorDB. 種々のエラーメッセージは色々なプログラムが生成します。 Xlib 内の標準のエラーハンドラ (多くのツールキットによっても使用されて いる) はエラー発生時の診断メッセージを作成する標準リソースを使用します。 これらのメッセージの標準は通常、<XRoot>/lib/X11/XErrorDB の中に 格納されています。 このファイルが無い場合はエラーメッセージはかなり簡単でなぞめいたものに なるでしょう。

might X Toolkit Intrinsics が遭遇するエラーをリソースの文字列から適切な内部書式に 変換するときは、エラーメッセージは通常出力されません。様々なディスプレイ (カラーとモノクロ、多くのフォントと少しのその他) のリソースの組み合わせを 手にいれたいときには便利ですが、とはいえアプリケーションがなぜ失敗したを 分かろうとするときはプログラムが停止するでしょう。この挙動は StringConversionsWarning リソースを設定することにより上書きできます。

X Toolkit Intrinsics が常に文字列変換のエラーを出力するように強制するには、 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, と 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 Window System の土台は元々 マサチューセッツ工科大学 (Massachusetts Institute of Technology) のコンピュータ科学研究所 (Laboratory for Computer Science) が開発し、それに全ての権利を X Consortium に 1994/01/01 付けで譲渡されました。 X Consortium, Inc. は 1996/12/31 付けで閉鎖致しました。X Window System に 関する全ての権利は Open Software Foundation へ譲渡されました。

翻訳者

岡本 一幸 Kazuyuki Okamoto <ikko-@pacific.rim.or.jp>