X(7) — NEWS-OS Programmer’s Manual

名称

X − ポータブルなネットワークトランスペアレントウィンドウシステム

形式

X は、様々な計算用および図形用のマシンで動作する MIT で開発された、ネットワークトランスペアレントなウィンドウシステムです。 MIT ソフトウェアの供給は、ほとんどの ANSI C および POSIX 準拠のシステムで、比較的容易に構築できます。商業上のインプリメンテーションも各種様々なプラットフォームで可能です。ソニーは、NEWS ワークステーション上の NEWS-OS 用をサポートします。

X コンソシアムは、本ソフトウェアについて述べる場合は、下記の名称を使用することを要請します。

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

X Window System は、マサチューセッツ工科大学 (MIT) の商標です。

解説

X ウィンドウシステムのサーバは、ビットマップディスプレイを備えたコンピュータ上で動きます。サーバは、様々な異なったプロセス間通信チャネルを介して様々なクライアントプログラムに対してユーザ入力を配布し、出力リクエストを受け付けます。最も一般的な例は、サーバと同じマシン上で動作するクライアントプログラムですが、クライアントを別のマシン (異なったアーキテクチャとオペレーティングシステムを備えたマシンも含む) から透過的に動かすこともできます。

X は、白黒およびカラーディスプレイの両方の上でオーバーラッピング (重複) 階層サブウィンドウおよびテキストとグラフィックスオペレーションをサポートします。利用できる機能についての完全な説明に関しては、Xlib − C 言語 X インターフェースマニュアル、 X Window System Protocol 仕様書、 X Toolkit Intrinsics - C 言語インターフェースマニュアル、および様々なツールキット文書を参照してください。

X を使用するプログラム数は、かなりたくさんあります。 MIT 供給物の主なプログラムには、以下のものがあります。端末エミュレータ (xterm)、ウィンドウマネージャ (twm)、ディスプレイマネージャ (xdm)、コンソールリダイレクトプログラム (xconsole)、メール管理ユーティリティ (xmh および xbiff)、マニュアルページブラウザ (xman)、ビットマップエディタ (bitmap)、リソースエディタ (editres)、 ditroff プレビュア (xditview)、アクセス制御プログラム (xauth および xhost)、ユーザ選択の設定プログラム (xrdb、xcmsdb、 xset、xsetroot、xstdcmap、および xmodmap)、ロードモニタ (xload)、クロック (xclock と oclock)、フォントディスプレーヤ (xfd)、フォント、ウィンドウ、およびディスプレイに関する情報をリストするためのユーティリティ (xlsfonts、xfontsel、xwininfo、 xlsclients、xdpyinfo、および xprop)、どのようなイベントがいつ発生したかを知るための診断 (xev)、スクリーンイメージ操作ユーティリティ (xwd、 xwud、 xpr、および xmag)、および様々なデモ (xeyes、ico、xgc、x11perf 等)。

他の多くのユーティリティ、ウィンドウマネージャ、ゲーム、ツールキットなどは、 MIT が供給するユーザ貢献ソフトウェアに含まれています。これらは、インターネットで anonymous ftp を使用して利用できます。詳細については、最寄りの現場のシステム管理者にお問い合わせください。

起動

X サーバとクライアントアプリケーションの初期セットを起動するには、現在 2 つの方法があります。どの方法を使用するか、どのようなオペレーティングシステムで実行するのか、および X 以外の他のウィンドウシステムを使用するか否かによります。

xdm (X ディスプレイマネージャ)
常に自分のディスプレイ上で X を動作させたい場合は、X ディスプレイマネージャ xdm を使用できるよう、現場のシステム管理者にマシンをセットしてもらうことができます。このプログラムは通常、ブート時にシステムによって起動され、サーバを動作させ続け、ユーザがログインできるようにします。 xdm を実行するとスクリーン上にウィンドウが現れ、あなたをシステムへ迎え入れ、ユーザ名とパスワードを尋ねてきます。通常端末におけるのと同様に、それらを単に入力し、入力ごとにリターンキーを押します。誤った入力を行うと、xdm はエラーメッセージを表示して、もう一度入力を行うよう要求してきます。ログインに成功すると、xdm は X 環境を起動します。ホームディレクトリ内に .xsession と命名された実行可能なファイルをもっている場合は、デフォルトによって、xdm はそれを実行するプログラム (あるいはシェルスクリプト) として扱い、最初のクライアント (端末エミュレータ、クロック、ウィンドウマネージャ、バックグラウンド、ポインタの速度のような事項に対するユーザ設定等) を起動します。詳細は現場のシステム管理者にお問い合わせください。

xinit (シェルから手動で起動される)
複数のウィンドウシステムをサポートしている現場では、X を手動で起動するのに xinit プログラムの使用を選択することもあります。あなたのマシンでそれを行う場合は、現場のシステム管理者は、現場固有の初期設定 (便利なデフォルトリソースのロード、ウィンドウマネージャの実行、クロックの表示、およびいくつかの端末エミュレータの起動等) を優れた方法で行う "x11"、 "startx" または "xstart" と命名されたプログラムをおそらく提供してくれるでしょう。提供されない場合は、xinit プログラムを使用してそのようなスクリプトを構築することができます。このユーティリティは、単に 1 つのユーザ指定のプログラムを実行して、サーバを起動し、別のプログラムを実行して希望するクライアントを起動し、そして次にどちらかが終了するまで待機します。ユーザ指定のプログラムのいずれかまたは両方ともがシェルスクリプトであるため、このことによって、優れたインターフェースには欠けることになりますが、かなり柔軟性がもたらされます。このため、xinit はエンドユーザ向けではありません。

ディスプレイ名

ユーザのために、あらゆる X サーバは以下の形式のディスプレイ名をもっています。

hostname:displaynumber.screennumber

この情報は、アプリケーションによって、どのようにサーバに接続を行い、どのスクリーンをデフォルトで使用すべき (複数のモニタを備えたディスプレイ上で) かを決定するのに使用されます。

hostname
hostname は、ディスプレイが物理的に接続されるマシン名を指定します。 hostname が指定されなかった場合は、同一のマシン上のサーバと通信を行うのに最も効率的な方法が使用されます。

displaynumber
用語 "ディスプレイ" は通常、共通キーボードとポインタ (マウス、タブレット等) を共有するモニタの集合体を指すのに使用されます。ほとんどのワークステーションは、キーボード１つしかもたず、したがってディスプレイ 1 つしかもたない場合が多いです。ただし、より大規模なマルチユーザシステムでは、複数の人間がグラフィックス作業を同時に行えるよう、いくつかのディスプレイをもつことがよくあります。混乱を避けるため、1 つのマシン上の各ディスプレイには、そのディスプレイに対する X サーバが起動される際に ディスプレイ番号 (0 から始まる) が割り当てられます。

screennumber
ディスプレイの中には、2 つ以上のモニタ間でキーボード 1 つとポインタ１つを共有するものもあります。各モニタは、独自の一連のウィンドウをもっているため、各スクリーンにはそのディスプレイに対する X サーバが起動される際に、スクリーン番号 (0 から始まる) が割り当てられます。スクリーン番号が指定されない場合は、スクリーン 0 が使用されます。

POSIX システムでは、デフォルトのディスプレイ名は、DISPLAY 環境変数内にストアされます。この変数は、xterm 端末エミュレータによって自動的に設定されます。ただし、ネットワーク上の別のマシンにログインする場合は、自分のディスプレイを指すように手動で DISPLAY を設定しなければなりません。以下に例を示します。

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

xon スクリプトは、リモートマシン上の X プログラムを起動するのに使用でき、自動的に、正しい DISPLAY 環境変数を設定します。

最後に、ほとんどの X プログラムは、DISPLAY の内容を一時的にオーバライドするのに、−display displayname のコマンド行オプションを受け付けます。これは通常、ウィンドウを別の人のスクリーン上にポップするのに使用したり、xterm が自分のディスプレイをもう一度指すように"リモートシェル"コマンドの 1部として使用されます。以下に例を示します。

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

X サーバは、様々な異なった通信チャネル (ネットワークバイトストリーム、共有メモリ等) 上の接続を待機 (listen) しています。特定のサーバと交信を行うにはいくつかの方法があり、ディスプレイ名の hostname 部分は、使用すべきチャネルのタイプ (トランスポート層とも呼ばれる) を決定するのに使用されます。一般的に、X サーバは下記のタイプの接続をサポートします。

local
ディスプレイ名のホスト部は空でなければなりません。たとえば、 :0, :1, :0.1 などです。ローカルで最も効率的なトランスポートが選択されます。

TCP/IP
ディスプレイ名の hostname 部分は、サーバマシンの IP アドレス名でなければなりません。 Internet のフルネーム、省略名、および IP アドレスはすべて許されます。たとえば、expo.lcs.mit.edu:0、 expo:0、 18.30.0.212:0、 bigmachine:1、および hydra:0.1。

DECnet
ディスプレイ名 hostname 部分は、サーバマシンのノード名とその後に 1 つではなく 2 つのコロンが付いたものでなければなりません。たとえば、myws::0、 big::1、および hydra::0.1。

アクセス制御

X サーバは、いろいろなタイプのアクセス制御を提供します。リリース 5 で提供されているメカニズムは、以下のものがあります。

   Host Access簡単なホストベースのアクセス制御
   MIT-MAGIC-COOKIE-1テキストの "cookies" を共有する
   XDM-AUTHORIZATION-1プライベートキーに基づいた Secure DES

xdm は、サーバのアクセス制御を初期化し、オーソリゼーション情報を、ユーザがアクセスすることのできるファイル内に書き込みます。通常は、接続が常に受け付けられるホストのリストは空です。そのため、明示的に認証されたクライアントだけがディスプレイに接続できます。このリストにエントリを追加する場合 (xhost で) は、サーバはそれ以上それらのマシンからの接続に関する認証を行いません。このことに注意してください。

Xlib がオーソリゼーションデータを取り出す用ファイルは、環境変数 XAUTHORITY で指定できます。デフォルトはホームディレクトリ内の .Xauthority というファイルです。 xdm は$HOME/.Xauthority を用います。 xdm はそれを作成するか、あるいはユーザがログインしたときにそれが既に存在するときそれをオーソリゼーションレコードにマージします。

複数のマシンを使用し、ネットワークファイルシステムを用いてそれらのマシン上で、共通のホームディレクトリを共有する場合は、オーソリゼーションファイルについてあまり心配する必要はありません。デフォルトで、システムは正しく動作します。それ以外の場合は、オーソリゼーションファイルはマシンに依存しないため、単にファイルをコピーして、共有することができます。オーソリゼーションファイルを管理するには、 xauth を使用してください。このプログラムで、レコードを抽出して、それらをファイルに挿入することができます。これを使用することにより、リモートマシンが、ユーザのローカルなマシン上で共通のホームディレクトリを共有しない場合でも、ログイン時に、リモートマシンに送ることができます。ネットワークファイルシステムあるいは 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 ピクセルだけ中に入ったところに置かれます。 XOFF は負数であることもありますが、その場合は、ウィンドウの右端はスクリーンからはみ出します。

Y オフセットも同じような意味をもちます。

+YOFF ウィンドウの上端は、スクリーンの上端から YOFF ピクセル下のところです (つまり、ウィンドウの原点の Y 座標は YOFF となります)。 YOFF は負数であることもありますが、その場合は、ウィンドウの上端はスクリーンからはみ出します。

−YOFF ウィンドウの下端は、スクリーンの下端から YOFF ピクセル上のところです。 YOFF は負数であることもありますが、その場合は、ウィンドウの下端はスクリーンからはみ出します。

オフセットはペアで与えなければなりません。すなわち、XOFF あるいは YOFF のどちらか片方を指定するには、両方いっしょにでなければなりません。ウィンドウは、下記の指定を使用すると、スクリーンの 4 つの隅に置くことができます。

+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 &

ウィンドウマネージャ

スクリーン上のウィンドウのレイアウトは、ウィンドウマネージャと呼ばれる特別なプログラムによって制御されます。多くのウィンドウマネージャは与えられたとおりのジオメトリ指定をそのまま受け付けますが、それ以外のウィンドウマネージャはそれらを無視することもあります (たとえば、ユーザに対して、ポインタでスクリーン上にウィンドウのリージョンを明示的に描くよう求めます)。

ウィンドウマネージャは系統立った (複雑であるにもかかわらず) クライアントプログラムであるため、様々な異なるユーザインターフェースを構築することができます。 MIT の配給物には、オーバーラッピングウィンドウ、ポップアップメニュー、 point-and-click または click-to-type の入力モデル、タイトルバー、よくできたアイコン (そして、独立したアイコンウィンドウの嫌いな人のためのアイコンマネージャ) 等々をサポートする twm と命名されたウィンドウマネージャが含まれます。

その他のウィンドウマネージャについては、 MIT が供給するユーザ貢献ソフトウェアを参照してください。

フォント名

X でテキストとシンボルを表示するための文字のコレクションを フォント と呼びます。フォントには通常、共通の外観を共有し、全体として見やすい形象が含まれます (たとえば、単一サイズ、ボールド、斜体、および文字セット等)。同様に、共通のタイプフェースに基づいたフォントのコレクション (その種類には、ローマ字、ボールド、イタリック体、ボールドイタリック体、斜線、およびボールドの斜線と呼ばれるものがあります) は、ファミリー と呼ばれます。

フォントは、様々なサイズで来ます。 X サーバは、 scalable フォントをサポートしています。これは、1 つのフォントのソースから、任意のサイズのフォントを作成できます。サーバは、 outline フォント、および bitmap フォントのスケールをサポートしています。通常、アウトラインフォントをスケールしたものの方が、ビットマップフォントをスケールしたものより、かなりよい結果が得られます。

X サーバは、ファイルシステムのディレクトリに格納されている個々のファイルから、あるいは、複数のフォントサーバから、あるいは、ディレクトリとフォントサーバの両方から、フォントを得ます。サーバがフォントを捜すときに見る場所のリストは、 フォントパス によって制御されます。インストレーションの多くは、フォントパス中の一般に使用されているフォントディレクトリを全てロードしてサーバを起動しますが、フォントパスは xset プログラムを使用して、いつでも変更することができます。ただし、ディレクトリ名はアプリケーションマシン上ではなく サーバ のマシン上にあることを忘れないことが大切です。

X サーバおよびフォントサーバが使用する一般的なフォントのほとんどは、以下の 4 つのディレクトリにあります。

/usr/lib/X11/fonts/misc
このディレクトリには、あらゆるシステムで利用できるいろいろなビットマップフォントが含まれています。これには、固定幅フォントからなるファミリ、 Dale Schumacher 提供の固定幅フォントからなるファミリ、ソニー (株) 提供のかなフォント複数、 JIS 漢字フォント 2 種類、 Daewoo Electronics 提供のハングルフォント 2 種類、 Joseph Friedman 提供のヘブライフォント 2 種類、標準のカーソルフォント、 Digital Equipment Corporation 提供のカーソルフォント 2 種類、 Sun Microsystems 提供のカーソルフォントとグリフフォント、などが含まれます。 fixed と variable というエイリアスも含め、フォントに対して、様々なフォント名のエイリアスがあります。

/usr/lib/X11/fonts/Speedo
このディレクトリには、 Bitstream 社の Speedo ラスタライザ用のアウトラインフォントが含まれます。 Bitstream 社により、　 1 つのフォントフェースに対し、ノーマル、ボールド、イタリック、ボールドイタリックで提供されています。

/usr/lib/X11/fonts/75dpi
このディレクトリには、 Adobe Systems 社、 Digital Equipment Corporation 社、 Bitstream 社、 Bigelow and Holmes 社、 Sun Microsystems 社によって寄贈された 1 インチあたり 75 ドットのディスプレイ用のビットマップフォントが含まれます。個々のファミリごとに、サイズ、スタイル、太さ、の完全なセレクションが提供されています。

/usr/lib/X11/fonts/100dpi
このディレクトリには、75dpi ディレクトリ内のフォントの中のいくつかの 1 インチあたり 100 ドットのバージョンが含まれます。

通常、ビットマップフォントファイルは、 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 つのうちのどちらかを、ゼロ以外の値に置き換えてください。最初のゼロを含むフィールドは、ピクセルサイズです。特定のサイズのフォントを指定するには、これを、特定の高さ (ピクセル値) と置き換えてください。同様に、 2 番目のゼロを含むフィールドは、ポイントサイズです。特定のサイズのフォントを指定するには、これを、特定サイズ (デシポイント値。722.7 デシポイント = 1 インチ) と置き換えてください。最後のゼロは、平均幅フィールドで、単位は、10 分の 1 ピクセルです。サーバによっては、この値が指定されている場合、無限にスケールします。

フォントサーバ名

以下の形式のいづれかで、 TCP 接続を受け付けるフォントサーバを指定します。

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

hostname には、フォントサーバが起動しているマシンの名前 (または、10 進数のアドレス値) を指定します。 port は、フォントサーバが接続を待機 (listen) している TCP ポート (10 進数) です。 cataloguelist には、’+’ で区切られた、カタログ名のリストを指定します。

例： tcp/expo.lcs.mit.edu:7000, tcp/18.30.0.212:7001/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 サーバのデータベースから、その色を捜します。このデータベースのテキスト形式は、通常、/usr/lib/X11/rgb.txt ファイルに保存されています。

数値による色指定は、以下の形式の、カラースペース名と、値のセットからなります。

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

RGB デバイス指定は、プリフィックス "rgb:" によって認識され、以下の形式で指定します。

    rgb:<red>/<green>/<blue>
         <red>, <green>, <blue> := h | hh | hhh | hhhh
        h := 1 文字の 16 進数値

h は、4 ビットにスケールされた値、 hh は、8 ビットにスケールされた値、 hhh は、12 ビットにスケールされた値、 hhhh は、16 ビットにスケールされた値、をそれぞれ指すので、ご注意ください。これらの値は、ガンマ修正されていると想定され、直接 X サーバに渡されます。

以下は、主な 8 色の表現です。

    blackrgb:0/0/0
    redrgb:ffff/0/0
    greenrgb:0/ffff/0
    bluergb:0/0/ffff
    yellowrgb:ffff/ffff/0
    magentargb:ffff/0/ffff
    cyanrgb:0/ffff/ffff
    whitergb:ffff/ffff/ffff

バックワードコンパチビリティのため、古い RGB デバイスの形式もサポートされていますが、これを引き続き使用するのはお勧めできません。形式は、最初にシャープサイン (#)、それに続いて、数値指定で、以下のいずれかの形式で指定します。

    #RGB(各 4 ビット)
    #RRGGBB(各 8 ビット)
    #RRRGGGBBB(各 12 ビット)
    #RRRRGGGGBBBB(各 16 ビット)

R、G、B は、それぞれ、1 文字の 16 進数を表します。各ビットに 16 ビットより少ないビットが指定された場合は、それは、その値の最上位ビットを表します。 (値がスケールされる、"rgb:" 形式とは異なります。) 例えば、#3a7 は、#3000a0007000 と同じです。

RGB の光度指定は、プリフィックス "rgbi:" によって認識され、以下の形式で指定します。

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

red、green、blue は、0.0 から 1.0 の間 (境界を含む) の浮動小数点値です。これは、 1.0 は、一番明るい光度、また、 0.5 は、一番明るい光度の半分の光度、というように、 1 次元の光度の値を表します。これは、 Xlib により、X サーバに送られる前にガンマ修正されています。これらの値の入力形式は、符合 (オプショナル)、数字 (小数点を含んだものも可)、乗数のフィールド (オプショナル) です。乗数のフィールドは、 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) は全て、浮動小数点値です。値によっては、ゼロからある上限までの値に、制限されるものもあります。各上限値は、上記のカッコ内に示されています。これらの値の形式は、正数 (小数点を含むものも可)、乗数フィールド (オプショナル) です。乗数フィールドは、そして、正数が続きます。

デバイスに依存しない色についての詳細は、 Xlib のマニュアルを参照してください。

アプリケーションの開発者は、それぞれの使用カラーをあつらえることができるように注意を払わなければなりません。

キーボード

X のキーボードモデルは、次の 2 つの層に分けられます。物理的キーを表すサーバ固有のコード (キーコード と呼ぶ)、およびキー上に現れる文字または単語を表すサーバに依存しないシンボル (keysyms と呼ぶ)。キーコードを keysyms に変換するために、サーバ内には 2 つのテーブルが保持されています。

modifier list (モディファイアリスト)
キーの中には、モディファイア として知られ、１つのキーに付加されている異なったシンボル (たとえば、Shift-a では大文字の A が生成され、 Ctrl-l では制御文字の ^L が生成される) を選択するのに使用されるものもあります。サーバは、種々のモディファイアに対応するコードのリストを保持しています。いつキーを押したり離したりしても、サーバは指示されたキーのキーコードを含む イベント ならびに、どのモディファイアキーが現在押されるかを指定するマスクを生成します。ほとんどのサーバは、最初からキーボード上の種々のシフト、コントロール、およびシフトロックキーを含むために、このリストをセットアップします。

keymap table (キーマップテーブル)
アプリケーションは keysym テーブル を使用して、イベントキーコードとモディファイアマスクを keysyms に翻訳します。 keysym テーブル は各キーコードについての一行と、様々なモディファイアの状態についての一列からなります。このテーブルは、通常のタイプライタの決まりに対応するようにサーバによって初期化されます。 keysyms を生成するのに、テーブルをどう解釈するかの正確なセマンティックは、プログラム、ライブラリ、使用する言語の入力方法に依存しますが、一般的に、各行の最初の 4 つの keysym は、以下のように変換されます。

リスト中の最初の 4 つの要素は、 2 つのグループの keysym に分けられます。最初グループには、1 番目と 2 番目の keysym が、 2 番目のグループには、3 番目と 4 番目の keysym が含まれます。各グループ内で、第 1 要素がアルファベットで、第 2 要素が特別な keysym、NoSymbol の場合は、そのグループは、第 1 要素が小文字で、第 2 要素が大文字のグループと同様に、扱われます。

グループ間の切り替えは、MODE SWITCH という名の keysym によって制御されます。これは、あるキーにその keysym を付け加え、モディファイア (Mod1 から Mod5 の内のどれか) にそのキーを付け加えて、制御されます。このモディファイアは、“グループモディファイア” と呼ばれるものです。グループ 1 は、グループモディファイアがオフの時に使用され、グループ 2 は、グループモディファイアがオンの時に使用されます。

モディファイアの状態により、グループ内のどちらの keysym を使用するかが決められます。最初の keysym は、Shift および Lock モディファイアがオフの時に使用されます。 2 番目の keysym は、 Shift モディファイアがオンの時、 Lock モディファイアがオンで、2 番目の keysym が大文字のアルファベットの時、あるいは、 Lock モディファイアがオンで、ShiftLock として解釈される時、に使用されます。それ以外の場合、 Lock モディファイアがオンで、CapsLock として解釈される時、 Shift モディファイアの状態が、まず keysym を選択するのに使用されます。しかし、その keysym が小文字のアルファベットの場合は、対応する大文字の keysym が代わりに使用されます。

オプション

ほとんどのプログラムは、コマンド行オプションと引数に対しては同じ名前を使おうとします。 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
セレクション要求のために通信するふたつのアプリケーションが相手の応答を待つ場合のタイムアウトをミリ秒で指定します。

−synchronous
このオプションは、X サーバに対するリクエストを、非同期的にではなく同期的に送信することを示します。 Xlib は通常、サーバに対するリクエストを緩衝記憶するので、エラーはそれが生じた直後に報告されないこともあります。このオプションは、アプリケーションをデバックできるよう、バッファリングを停止します。これは、決してワーキングプログラムとともに使用してはなりません。

−title string
このオプションは、このウィンドウに対して使用するタイトルを指定します。この情報を、ウィンドウを識別するなんらかの見出しを提供するために、ウィンドウマネージャが用いることもあります。

−xnllanguage language[_territory][.codeset]
リソースや、それ以外にファイル名などを解釈する際の言語、地域、コードセットを指定します。

−xrm resourcestring
このオプションは、任意のデフォルトをオーバライドするためのリソース名と値を指定します。これはまた、明示的なコマンド引数をもたないリソースを設定するのに非常に役に立ちます。

リソース

アプリケーションを各個人の好みに、より簡単に合わせることができるように 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 に対し、2 つ以上のエントリを持つことはありません。リソースファイルに、同じ ResourceName を持つ行が複数ある場合は、そのファイルの最後に指定された行が使用されます。

ResourceSpec 中の名前またはコロンの前後の空白文字は無視されます。 Value に空白文字を使用させたい場合は、 “\space” (バックスラッシュの後にスペース) という 2 文字がスペース文字と認識され、置き換えられます。また、 “\tab” (バックスラッシュの後にタブ) という 2 文字がタブ文字と認識され、置き換えられます。 Value に改行を含ませたい場合は、 “\n”という 2 文字が復帰改行文字と認識され、置き換えられます。 Value をテキストファイル中で複数行に分けて書きたい場合は、 “\newline” (バックスラッシュの後に復帰改行文字) という 2 文字が認識され、取り去られます。 Value に任意の文字コードを使用したい場合は、 “\nnn”という 4 文字 (各 n は、0 から 7 までの数字) が、その並びで指定した 8 進数の値を含む 1 バイトと認識され、置き換えられます。そして、 “\\” という 2 文字が、 1 文字のバックスラッシュと認識され、置き換えられます。

アプリケーションがリソース値を検索するときは、階層の完全なパス名 (クラス名とインスタンス名の両方) を指定します。しかし、通常、リソース値は、パターンマッチを用いて、名前やクラスの一部しか与えられません。アスタリスク (∗) は、バインディングが甘く、そこに、ゼロ個以上の要素を表すのに用います。ピリオド (.) は、バインディングが厳しく、隣接の要素を分けるのに使用されます。クエッションマーク (?) は、1 つの要素名またはクラスと一致します。データベースのエントリの最後に、甘いバインディングを使用することはできません。最後の要素 ("?" は、使用できません) は、指定しなければいけません。検索アルゴリズムは、指定された完全な名前とクラスに、最もよく一致するエントリ (最も特定の) をリソースデータベースから検索します。 2 つ以上のデータベースのエントリが完全な名前とクラスに一致した場合は、優先法則が使用し、1 つだけ選択します。完全な名前およびクラスは、左から右へ (階層の一番上のレベルから一番下のレベルへ)、 1 要素ずつスキャンされます。各レベルで、一致する各エントリに対応する要素、および/またはバインディングが決定され、一致した要素とバインディングが優先法則に基づいて比較されます。他の全ての中から 1 つのエントリが選ばれるまで、この法則の全てが、次のレベルに移動する前に、各レベルで適用されます。法則 (優先順位) は、以下のとおりです。

1.一致する要素を含むエントリ (名前、クラス、または "?") は、レベルを省略したエントリ (つまり、曖昧なバインディングでレベルと一致するエントリ) より、優先度があります。

2.名前が一致するエントリは、クラスが一致するエントリおよび "?" を使用して一致するエントリより、優先度があります。クラスが一致するエントリは、 "?" を使用して一致するエントリより、優先度があります。

3.厳しいバインディングが先にあるエントリは、甘いバインディングが先にあるエントリより、優先度があります。

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

アプリケーション固有のファイル
環境変数 XUSERFILESEARCHPATH あるいは XAPPLRESDIR で指定されたディレクトリと、標準のディレクトリ (通常 /usr/lib/X11/ の下、環境変数 XFILESEARCHPATH の値でオーバーライドされる) で、アプリケーション固有なリソースファイルを探します。例えば、アプリケーションのデフォルトリソースは、通常、/usr/lib/X11/app-defaults/ にあります。詳細はマニュアル X Toolkit Intrinsics - C Language Interface を参照して下さい。

XENVIRONMENT
あらゆるユーザおよびマシン固有のリソースは、すべてのアプリケーションによってロードされるリソースファイル名に XENVIRONMENT 環境変数を設定することによって指定することができます。この変数が定義されない場合は、.Xdefaults-hostname (ここで、hostname は、アプリケーションが実行されているホスト名) というファイルが捜されます。

−xrm resourcestring
リソースは、コマンドからも指定できます。 resourcestring は、上述のとおりの単一のリソース名と値です。なお、文字列にシェルによって解釈される文字 (たとえば、アスタリスク) が含まれる場合は、それらを引用符で囲まなければなりません。任意の数の −xrm 引数をコマンド行上に与えることができます。

プログラムリソースは、classes と呼ばれるグループに編成されるので、個々のリソース (各々が instances と呼ばれる) のコレクションを１度に設定することができます。規則により、リソースのインスタンス名は小文字で始まり、クラス名は大文字で始まります。複数の語のリソースは、後続する大文字になった語の最初の文字と連結されます。 X ツールキットイントリンシックで書かれたアプリケーションは、少なくとも以下のリソースをもちます。

background (クラス Background)
このリソースは、ウィンドウのバックグラウンドの色を指定します。

borderWidth (クラス BorderWidth)
このリソースは、ウィンドウボーダの幅をピクセル単位で指定します。

borderColor (クラス BorderColor)
このリソースは、ウィンドウボーダの色を指定します。

X ツールキットイントリンシックを用いたほとんどのアプリケーションは、foreground (クラス 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 マニュアルの リソースマネージャの機能 の項を参照ください。

例

下記は、しばしば使用されるコマンドに対するコマンド行の例を列挙したものです。個々のコマンドについての情報に関しては、マニュアル中のそれぞれのコマンドの項を参照してください。

    % 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 のデフォルトエラーハンドラ (他の多くのツールキットによっても使用される) は、標準リソースを使用して誤りが生じた場合に診断メッセージを作成します。それらのメッセージに対するデフォルトは通常、/usr/lib/X11/XErrorDB にストアされます。このファイルが存在しない場合は、エラーメッセージはやや簡潔で暗号化されたようなものとなります。

X ツールキットイントリンシックが、リソース文字列を適切な内部フォーマットに変換する際のエラーに出会った場合は、エラーメッセージは通常表示されません。これは、一連のリソースを様々なディスプレイ (たとえば、カラー対白黒、多数のフォント対小数のフォント等) 全体を通じてもつのが望ましいときに便利です。ただし、あるアプリケーションがなぜ失敗するのかを判断しようとする場合に問題を生じることもあります。 StringConversionsWarning リソースを設定することによって、この動作をオーバライドすることができます。

X ツールキットイントリンシックに常に文字列変換エラーメッセージを表示させるために、 xrdb プログラム (ユーザのホームディレクトリ内の .Xresources あるいは .Xres と呼ばれることが多い) を使用して、 RESOURCE_MANAGER プロパティにロードされるファイルに下記のリソースを置かなければなりません。

∗StringConversionWarnings: on

ある特定のアプリケーションに対してだけ変換メッセージを表示するには、適切なインスタンス名をアスタリスクの前に置きます。

xterm∗StringConversionWarnings: on

著作権

下記の著作権と許可通告は、MIT による X ウィンドウシステムの標準配給物の大部分にあてはまる権利と制限を概略したものです。その他の部分は、追加のまたは異なる著作権と許可をもっています。個々のソースファイルを参照のこと。 Copyright 1984, 1985, 1986, 1987, 1988, 1989, 1990, 1991 by the Massachusetts Institute of Technology. 本ソフトウェアとその資料を何らかの目的で無料で使用、複写、修正、配布、販売することは、上記の著作権通告がすべてのコピーに記載され、その著作権通告と本許可通告がサポート資料に記載され、また、特別な書面による事前の許可なくしてソフトウェアの販売に関係する広告や宣伝に MIT の名称を使用しないことを前提として許可するものとする。 MIT は、あらゆる目的に対する本ソフトウェアの適合性に関しては何の表示も行わない。本ソフトウェアは、明示的にも暗示的にもいかなる保証も行わず、 "そのまま" で供給される。

商標

X Window System は MIT の商標です。

著者

非常に多くの人々。 MIT リリース 5 の配布は MIT X Consortium によって行われました。携わった人の名前は、各ドキュメントおよびソースファイルに書かれています。このリリースに関する MIT の責任者は以下の人々です。 Donna Converse (MIT X Consortium), Stephen Gildea (MIT X Consortium), Susan Hardy (MIT X Consortium), Jay Hersh (MIT X Consortium), Keith Packard (MIT X Consortium), David Sternlicht (MIT X Consortium), Bob Scheifler (MIT X Consortium), and Ralph Swick (Digital/MIT Project Athena).

NEWS-OSRelease 4.2.1R

Museum

Related Articles