library home hp.com home products and services support and drivers solutions
cd-rom home
End of Jump to page title
HP OpenVMS Systems
Documentation

Jump to content


互換性を維持するためのコーディング

[ 前のページ ] [ 次のページ ] [ 目次 ] [ 索引 ]


10 互換性を維持するためのコーディング

この章では,複数のハードウェア・プラットホームを対象としたDECwindows のアプリケーションを作成する際に従わなければならない,互換性を維持するためのコーディングについて説明します。 また,そのプログラム例も示します。

この章では次のトピックについて説明します。

10.1 互換性の重要性

DECwindowsのアプリケーションをコーディングするときには,アプリケーションの表示に使用するハードウェアのタイプを固定できません。 たとえば, ユーザはアプリケーションをOpenVMSクラスタ・ノードで実行し,それをPC の画面に表示するかもしれません。したがって,アプリケーションで画面のサイズを仮定してしまうと, 正しく表示されない可能性があります。

DECwindowsのアプリケーションは,ディスプレイ装置に依存しないようにコーディングすることができます。 以降の節で,互換性を維持するためのコーディングとその例について説明します。

10.2 フォント・フォールバック

Motif環境でアプリケーションが一貫性をもつように,できるだけシステムの省略時のフォントを使用してください。 しかし,アプリケーション固有の目的のために, 特別のフォントを使用しなければならない場合もあるでしょう。DECwindows では,アプリケーションで使用するフォントを指定できます。 フォント・フォールバックとは,指定したフォントが使用できない場合に2 番目に選択したフォントを使用することです。

DECwindowsのサーバにバンドルされているフォントには,DECが提供するフォントとMIT X11 リリース5で提供するフォントが含まれています。DEC のフォントはすべてのDECwindowsのサーバで利用できますが,他のメーカのワークステーションやPC 上で実行して結果を表示する場合には利用できません。 このような場合,アプリケーションは別のフォントを利用できなければなりません。

アプリケーションがフォント・フォールバック処理を行う方法は,UILルーチンまたはツールキット・ ルーチンのいずれを使用して,フォントを指定するかによって異なります。

次の各節で,フォント・フォールバックについてさらに詳しく説明します。

10.2.1 フォントの命名規則

ScheiflerおよびGettysによる『X Window System』のPart IVにX11のフォント命名規則が説明されています(『VMS DECwindows Xlib Programming Volume』にも同じく説明があります)。

Xlibのフォント名は次の各フィールドから構成され,左から右の順に並んでいます。

  1. フォントを作成した会社,またはフォント設計者

  2. フォントの書体のファミリ

  3. ウェイト(Book,Demi,Medium,Bold,light)

  4. スタイル(R (ローマン体),I (イタリック体),O (斜体))

  5. フォントの水平方向の単位あたりの幅(Normal,Wide,Double Wide,Narrow)

  6. 追加のスタイル・フォント識別子(通常は指定しない)

  7. ピクセル・フォント・サイズ

  8. ポイント・サイズ(8,10,12,14,18,24)の10倍表示

  9. インチあたりのピクセル/ドットで表したXの解像度

  10. インチあたりのピクセル/ドットで表したYの解像度

  11. 間隔(P (プロポーショナル),M (モノスペース),C (文字セル))

  12. フォント内のすべての文字の平均幅

  13. 文字セットの登録番号

  14. 文字セットの符号

代表的なフォントのフルネームは次のとおりです。


        1             2             3   4   5    6 7  8   9  10 11 12  13     14

     -ADOBE-ITC Avant Garde Gothic-Book-R-Normal--14-100-100-100-P-80-ISO8859-1

この例では,

  1. フォント作成会社はAdobe

  2. フォントの名前はITC Avant Garde Gothic

  3. フォント・ウェイトはBook

  4. フォントのスタイルはR (ローマン体)

  5. フォント単位あたりの幅はNormal

  6. 追加のスタイル・フォント識別子は空白

  7. ピクセル・サイズは14

  8. ポイント・サイズは10 (100/10)

  9. インチあたりのドット(dpi)で表した水平方向の解像度は100

  10. インチあたりのドット(dpi)で表した垂直方向の解像度は100 (dpiが100の場合,10ポイントにするには14ピクセルが必要)

  11. フォント間隔はプロポーショナル

  12. 文字の平均幅は80

  13. 文字セットの登録番号はISO8859

  14. 文字セットの符号はLatin-1

10.2.2 フォント・フォールバックの実現

DECwindows Motifツールキットはまず,指定されたフォントをロードしようとします。 指定されたフォントがロードできない場合は,表 10-1 および表 10-2のフォールバックを使用します。

フォント・フォールバック処理では,DECwindowsおよびMIT X11リリース4 のサーバ・フォントをはじめ,ディスプレイ上で利用できるフォントであれば何でも使用します。 アスタリスクはワイルドカードを意味します。

表 10-1 フォント・フォールバック

フィールド フォールバック
(作成会社)
Terminal以外のすべて Adobe
(フォント・ファミリ)
ITC Avant Garde Gothic Helvetica
ITC Lubalin Graph New Century Schoolbook
Menu Helvetica
ITC Souvenir Times
その他 Fixed
(ウェイト)
Menuファミリ Bold (ウェイトの他のフォールバックより優先する)
Bookのウェイト Medium
Demiのウェイト Bold
Lightのウェイト Medium
(スタイル)
ITC Lubalin GraphファミリおよびO 傾斜 Italic
(ウェイト)
すべてのAVERAGE_WIDTH 値 *
(ピクセル・サイズ)
* *
(DPIが100 の場合のピクセル・サイズ)
10 11
13 14
16 17
19 20
24 25
33 34

表 10-2 Terminalのフォント・フォールバック

フィールド フォールバック
(作成会社)
* *
75 DPIの場合 DEC
100 DPIの場合 Bitstream
(ピクセル・ サイズ)
* *
75 DPIの場合 14
100 DPIの場合 18
(セット幅名)
すべてのSETWIDTH_NAME 値 Normal
(ポイント・ サイズ)
すべてのPOINT_SIZE 値 140
(平均幅)
すべてのAVERAGE_WIDTH値 *


注意
フォント・フォールバックでは, すべてのフォント名のフィールドを再マップするわけではありません。 たとえば,xおよびyの解像度のフィールド(インチあたりのピクセル/ ドット単位)は,再マップされません。また,すべての画面が75 DPIと100 DPI のフォントをサポートするわけではないので,互換性上の問題を避けるために, このフィールドではワイルドカードを使用することができます。

新規のフォント名を作成する場合も,再マップされないフォント名フィールドは変更されません。


ファミリ,ウェイト,スタイル,幅,文字セットの登録番号,文字セットの符号のいずれかのフォント名フィールドでワイルドカードを使用する場合や, ハイフンが正しく配置されていなかったり抜けていたりして,フォント名の構文が解析できない場合は,Fixed フォントが返されます。Fixed フォントでは,端末の線画文字を使用できないことに注意してください。

10.2.3 共通フォントの使用

アプリケーションがフォントの指定にツールキット・ルーチンを使用しているが, フォント・フォールバックのためにDXmLoadQueryFontルーチンやDXmFindFontFallback ルーチンを使用しない場合は,DECwindowsとMIT X11 リリース5の両方のサーバに共通なフォントだけを使用しなければなりません。

UILおよびDXmLoadQueryFontルーチンとDXmFindFontFallbackルーチンを使用してフォント・ フォールバックを実現するのが,最適なフォントを見つけるもっとも確実な方法です。 ただし,アプリケーションがDECwindowsとMIT X11 リリース5の両方のサーバに共通なフォントだけを使用する場合は,MIT フォントをサポートする他のメーカのワークステーションに,そのアプリケーションを表示することができます。

DECwindowsとMIT X11リリース5の両方に共通なフォント・ファミリは,次のとおりです。

10.2.4 UILによるフォント・フォールバックの実現

FONT機能とVALUE宣言を使用すると,UILを通してフォント・リストを作成することができます。 次に示すUILコードは,FONT機能とVALUE宣言を使用してフォントを定義する例です。


     VALUE

     k_button_font  :

          font('-ADOBE-Courier-Bold-R-Normal--14-140-75-75-M-90-ISO8859-1');

このフォントに関連するウィジェットをフェッチする際にフォントが利用できない場合,DECwindows Motif ツールキットは,第10.2.2項で説明したようにフォールバック・ フォントを決定します。

何らかの理由で,フォント・フォールバックの実現がアプリケーションにとって適切でない場合は, フォントの指定にUILを使用しないでください。UIL の代わりにツールキット・ルーチンを使用して,フォールバック・ フォントを選択してください。

10.2.5 ツールキット・ルーチンによるフォント・ フォールバックの実現

例 10-1のプログラムはフォント・ リストを作成し, それを使用してCSTextウィジェットで使用するフォントを指定します。

例 10-1 ツールキット・ルーチンによるフォント・フォールバック


#include <stdio>

#include <Mrm/MrmAppl.h>

#include <DXm/DXmCSText.h>



static void change_cs();

static void ok_text();



Widget toplevel, text_shell,

       text_label, text_w,

       ok_button;



int main(argc, argv)

    unsigned int argc;

    char **argv;

{

    XtAppContext app_context;

    Arg arglist[15];

    int ac = 0;

【1】XFontStruct *font;

【2】XmFontList font_list;

    XtCallbackRec   callback_arg[2];



    toplevel = XtAppInitialize(&app_context, "example", NULL, 0, &argc,

                               argv, NULL, NULL, 0);



    ac = 0;

    XtSetArg( arglist[ac], XmNdialogTitle,

                         XmStringCreateLtoR("User Defined",""));ac++;

    XtSetArg( arglist[ac], XmNallowOverlap, TRUE);ac++;

    XtSetArg( arglist[ac], XmNheight, 300);ac++;

    XtSetArg( arglist[ac], XmNwidth, 300);ac++;

    XtSetArg( arglist[ac], XmNresizePolicy, XmRESIZE_GROW);ac++;



    text_shell = XmCreateBulletinBoard(toplevel, "CSText", arglist, ac );



    ac = 0;

    XtSetArg( arglist[ac], XmNlabelString,

              XmStringCreateLtoR("Enter a 10-letter title\nfor this widget",""));ac++;

    XtSetArg( arglist[ac], XmNx, 90);ac++;

    XtSetArg( arglist[ac], XmNy, 20);ac++;

    text_label = XmCreateLabel(text_shell, "textlabel",

arglist, ac );



【3】font = DXmLoadQueryFont( XtDisplay (toplevel),

                "-ADOBE-Courier-Bold-R-Normal--14-140-*-*-M-90-ISO8859-1");



【4】if (font == NULL){

               printf("Fonts Are Not Available");

               exit(0);

       }



【5】font_list = XmStringCreateFontList(font, XmSTRING_DEFAULT_CHARSET);



    callback_arg[0].callback = change_cs;

    callback_arg[0].closure = 0;

    callback_arg[1].callback = NULL;

    callback_arg[1].closure = NULL;



    ac = 0;

【6】XtSetArg( arglist[ac], XmNfontList, font_list ); ac++;

    XtSetArg( arglist[ac], XmNx, 40);ac++;

    XtSetArg( arglist[ac], XmNy, 100);ac++;

    XtSetArg( arglist[ac], XmNrows, 2 ); ac++;

    XtSetArg( arglist[ac], XmNcolumns, 35 ); ac++;

    XtSetArg( arglist[ac], XmNmaxLength, 10 ); ac++;

    XtSetArg( arglist[ac], XmNactivateCallback, callback_arg);ac++;



    text_w = DXmCreateCSText(text_shell, "textwidget", arglist, ac );



【7】XmFontListFree (font_list );



    XtManageChild(text_w);



    XtManageChild(text_label);

    XtManageChild(text_shell);



    XtRealizeWidget(toplevel);



    XtAppMainLoop(app_context);



 }



   .

   .

   .

  1. 変数fontをXフォント構造体へのポインタとして宣言します。

  2. 変数font_listをフォント・リストとして宣言します。

  3. DXmLoadQueryFontルーチンが,指定されたフォントをロードしようとします。 指定されたフォントがロードできない場合,フォールバック・ フォントがロードされます。フォントがロードされると,そのフォントのXFontStruct へのポインタが返されます。返されたフォントのID を必要とするアプリケーションは,そのフォントのプロパティをアクセスして, 必要な情報を取得できます。

  4. 何らかの理由でフォントをロードできない場合は,NULLが返されます。

    また,DXmFindFontFallbackルーチンを使用することもできます。 これを使用すると,フォント名を指定してフォールバック・フォント名を受け取ることができます。 その後,アプリケーションはXlib XLoadFontルーチンを呼び出して,フォールバック・フォントのロードを試みることができます。

  5. XmStringCreateFontListルーチンはフォント・リストを作成します。 この例では,CREATE FONT LISTルーチンに対する最初の引数が,DXmLoadQueryFont ルーチンによって返されたXフォント構造体を指定します。 このルーチンに対する2番めの引数は,文字セットを識別する定数です。

  6. CSTextウィジェットがテキストの表示に使用するフォントを指定するために, フォント・リストが使用されます。

  7. フォント・リストを使用したのち,そのフォント・リストに関連するメモリを解放します。

10.3 画面の独立性

プログラマはアプリケーションが表示する画面についての仮定をしてはなりません。 この節では,画面の独立性に関係するいくつかの互換性の問題について説明します。

10.3.1 画面のDPIについての仮定

第10.2.2項で説明したように, すべての画面が75 DPI と100 DPIのフォントをサポートするわけではありません。 画面の互換性上の問題を避けるため,xおよびyの解像度のフィールドにワイルドカードを使用できます。 次に例を示します。


     VALUE

     k_button_font  :

          font('-ADOBE-Courier-Bold-R-Normal--14-140-75-75-M-90-ISO8859-1');

たとえばこの場合,xおよびy解像度のフィールドにワイルドカードを使用すると次のようになります。


     VALUE

     k_button_font  :

          font('-ADOBE-Courier-Bold-R-Normal--14-140-*-*-M-90-ISO8859-1');

10.3.2 マルチヘッド・サーバのサポート

DECwindowsは複数の画面をもつサーバをサポートします。このようなシステムを マルチヘッド・ディスプレイと呼びます。

DECwindowsのサーバは現在,最高2つの画面をサポートします。ただし, ほかのベンダーのサーバを使用すると,追加の画面をサポートできる場合があります。

DECwindowsのアプリケーションを作成する際には,ディスプレイの画面0 (省略時の設定),画面1,またはその他の画面のいずれでアプリケーションを実行するかを仮定してはなりません。 アプリケーションを実行する画面はプログラマが仮定するのではなく, コマンド行の引数あるいはSET DISPLAYコマンドを使用して,ユーザに指定させます。

アプリケーション中に画面番号0をコーディングすると,ユーザはアプリケーションをほかの画面に表示することができません。 同様に,画面番号1 をコーディングすると,ユーザはそれ以外の画面にアプリケーションを表示することができません。

画面番号をアプリケーション中にコーディングすると,厳しく制約されることになります。 たとえば,プログラマが画面番号1をコーディングし, サーバが省略時の画面(画面0)しかもっていない場合,アプリケーションはディスプレイをオープンすることができません。

アプリケーションはディスプレイをオープンする前に,いくつの画面が接続されているかを事前に判断できません。 画面情報を返すXlibルーチンはすべて, まずディスプレイのオープンを必要とします。たとえば,先にディスプレイをオープンしなければ, アプリケーションはXScreenCountやXScreenofDisplay といったXlibルーチンを呼び出すことはできません。

10.3.2.1 XtAppInitializeルーチンによる画面指定

DECwindows Motifツールキットのアプリケーションは,通常XtAppInitialize ルーチンを呼び出して,ツールキットの初期化と画面のオープンを行います。XtAppInitialize ルーチンは,コマンド行の引数が存在する場合はその引数を使用し, コマンド行の引数が存在しない場合は, 前回のDISPLAY環境変数(UNIX, Windows NT)あるいはDISPLAY論理名(OpenVMS )を使用して,使用するディスプレイと画面を決定します。 このように,XtAppInitializeルーチンは省略時のディスプレイと画面を使用し, それ以外の方法で使用するディスプレイと画面を明示的に設定することはありません。

10.3.2.2 XtOpenDisplayルーチンによる画面指定

ツールキットを初期化せずに,特定のディスプレイや画面への接続をオープンする場合は,XtOpenDisplay ルーチンを呼び出して,ディスプレイのオープンと初期化, およびアプリケーション・コンテキストへの追加を行うことができます。

XtOpenDisplayルーチンは指定されたディスプレイ名を使用して,XlibルーチンのXOpenDisplay を呼び出します。引数display nameがNULLの場合, XtOpenDisplayはコマンド行の引数argvalueに指定されているディスプレイ・ オプションの現在の値を使用します。引数argvalueにディスプレイが指定されてない場合,XtOpenDisplay は前回のDISPLAYコマンドの結果を使用します。

引数display nameのフォーマットは hostname:number.screen(UNIX, Windows NT)あるいはhostname::number.screen(OpenVMS)です。 このとき,hostnameはホストのネットワーク名,numberはホスト上のサーバの番号, screenは使用する画面の番号です。現在のところ,DECwindows のサーバでは画面番号は0または1のいずれかが使用可能ですが, ほかのベンダーのサーバでは追加の画面を使用することもできます。

特にアプリケーションで画面1を使用したい場合は,XtOpenDisplayへの呼び出しで画面1 を指定し,XtOpenDisplayが異常終了を示すNULLを返すかどうかを確認します。

10.3.3 ウィンドウ・サイズの調整

アプリケーションをPCやその他の小さな画面に表示する場合,アプリケーションのウィンドウが大きすぎて, 画面に収まらないことがないように注意する必要があります。

この節では,ウィンドウ・サイズを調整するための2つの方法について説明します。

その他にもウィンドウ・サイズを調整する方法はあります。

10.3.4 スクロールするウィンドウの使用

スクロール・バーを備えたXmMainWindowウィジェットや,スクロール・バーを備えたXmBulletinBoardDialog ウィジェットなど,スクロールするウィンドウを使用して, 小さな画面に大きなウィンドウを表示することができます。 この方法はウィンドウ全体を一度に表示できないという欠点があります。 つまり,ウィンドウのすべての部分を表示するためには,ユーザはスクロール・ バーを使用しなければなりません。このため,ユーザはプッシュ・ ボタンや他のウィジェットを見つけるために,スクロール・バーを使用しなければならない場合もありますが, 確実にアプリケーション・ インターフェイスを利用できます。

アプリケーションを作成する際に,画面のサイズは考慮せず,すべての大きなウィンドウ, および大きくなる可能性のあるウィンドウに,自動的にスクロール・ バーを含めることができます。XtNscrollBarDisplayPolicy リソースをXmAS_NEEDEDに,XmNscrollingPolicyリソースをXmAUTOMATICに設定すると, 必要な場合だけスクロール・バーが表示されます。スクロール・ バーがまったく必要ないこともありますが,いつでも利用できる状態にあります。

10.3.5 DXmNfitToScreenPolicyリソースの使用

アプリケーションのデフォルト・ファイルにDXmNfitToScreenPolicyリソースを指定すると,Dialog ウィジェットのサイズを画面に合せて自動的に調整することができます。DXmNfitToScreenPolicy はDialog Shellウィジェットのリソースです。 アプリケーションのデフォルト・ファイルでDXmNfitToScreenPolicy リソースをAS_NEEDEDに設定すると,Dialog Shell ウィジェットは,画面に対して大きすぎるすべてのDialog Shellウィジェットのサイズを自動的に変更して配置します。

サイズ変更を行うと,Dialog Shellウィジェットは独自のスクロール・バーを作成するため, ユーザはこのスクロール・バーを使用して,ダイアログ・ ボックスの隠れている部分を表示することができます。

DXmNfitToScreenPolicyリソースはアプリケーションのデフォルト・ファイルでのみ設定することができ,UIL モジュール,またはXtSetArgへの呼び出しを通して設定することはできません。 このリソースを設定するためのフォーマットは次のとおりです。


     *DXmfitToScreenPolicy: AS_NEEDED


注意
DXmNfitToScreenPolicyリソースはDialog Shell ウィジェットにのみ影響を与えます。つまり,このリソースを設定することによって, アプリケーションのメイン・ウィンドウや最上位のシェルに影響を与えることはありません。

10.3.6 画面が小さい場合のウィンドウの配置

Motifのウィンドウ・マネージャは,画面のサイズに関係なく,画面の境界によってウィンドウが隠れないように配置できる場合にはそのように配置します。 ウィンドウが隠れてしまう場合は,ウィンドウの左上の角だけは画面に表示されるように配置します。 したがって,XmNyやXmNyリソースをウィジェットに設定する際に, 特別な注意を払う必要はありません。

10.4 カラーのサポート

DECwindowsのアプリケーションの視覚的な効果を高めるために,カラーを使用することができます。 ただし,カラーがどのようにサポートされて表示されるかについては, ディスプレイ装置のビジュアル・タイプと利用できるカラー資源により異なります。

各画面はそれに関連する1つまたは複数のビジュアル・タイプ をもっています。ビジュアル・タイプは,カラー機能またはモノクロ機能などの画面の特性を示します。 ビジュアル・タイプは画面上におけるカラーの表示を部分的に決定するとともに, 指定された画面に対してクライアントがカラーマップを操作できる方法を決定します。

アプリケーションを作成する際に,ディスプレイ装置または利用できるカラー資源について仮定することはできません。

特に,アプリケーションを作成する際には次のような制約があります。

これらの条件は,アプリケーションが複数のハードウェア・プラットホームで表示される場合は特に重要です。

次の各節では,複数のハードウェア・プラットホームで表示されるカラーを使用したアプリケーションをコーディングする際に, 従わなければならない項目について説明します。

DECwindowsのカラーの実現方法についての詳しい説明は,『X Window System』を参照してください。ここでは『VMS DECwindows Xlib Programming Volume』で説明している内容の概要を示します。

10.4.1 使用するカラーとディスプレイのタイプの一致

カラーを使用する際の基本的な方針は,アプリケーションでカラーを使用する必要性を明らかにしたのち, どのようにすればディスプレイ装置がそれらの必要性をサポートできるかを判断することです。

したがって,カラーを定義する前に,次の方法で画面の省略時のビジュアル・ タイプを判断してください。

  1. 画面の省略時のビジュアルを判断するため, XDefaultVisualofScreenルーチンを呼び出す。Xlibはビジュアル・データ構造体のアドレスを返す。

  2. ビジュアル・タイプを判断するため,データ構造体のXVisual.class を調べる。

VMS DECwindowsは表 10-3に示すビジュアル・ タイプを定義します。

表 10-3 DECwindowsのビジュアル・タイプ

ビジュアル・タイプ カラーマップ 説明
Pseudocolor 読み込み/ 書き込み Pseudocolorはフルカラーである。1つのピクセル値は, 赤,緑,青の定義から構成される1つのカラーマップを指す。 カラー・マップには,1つの色に対して赤,緑,青の構成値が格納されている。 カラー・インデックスはそのカラーマップの1つの項目を直接参照する。 セルにRGB値が重複なく割り当てられている場合,RGBの値は動的に変化する。

PseudocolorはDECの4プレーンおよび8プレーンのシステムにおける省略時のビジュアル・ タイプである。

Gray scale 読み込み/書き込み Gray scale は白黒である。ピクセル値が指すのがグレーの濃淡だけを生成するカラーマップであることを除き,Gray scale はPseudocolorと同じである。 グレーの濃淡はカラーマップに定義されており,各定義は白の明暗のレベルを定義する構成要素を1 つだけもっている。
Direct color 読み込み/書き込み Direct colorはフルカラーである。ピクセル値とカラーマップはともに, 赤,緑,青の3つの独立した部分に分けられている。ピクセル値の赤の部分はカラーマップの赤の部分を指し, ピクセル値の緑の部分はカラーマップの緑の部分を指し, ピクセル値の青の部分はカラーマップの青の部分を指す。 カラーマップの3つの部分によって完全な色の定義が行われる。

XAllocColorPlanesルーチンを使用してDirect colorモデルにカラー資源を割り当てる場合,RGB のうちの1つだけが異なる複数のピクセル値は,他の2 つの部分が指すカラーマップ項目を共用する。たとえば,2つの異なるピクセル値( ピクセルAとピクセルBとする)が,異なる赤のカラー・セルを指し, 同じ緑と青のカラー・セルを指しているとする。この場合, XStoreColorsを使用して,ピクセルAが指しているカラー・セルのRGB値を変更すると, ピクセルBが指している共用カラー・セルの値も変わる。

セルにRGB値が重複なく割り当てられている場合,RGBの値は動的に変化する。

True color 読み込み専用 True colorはフルカラーである。True color は,カラーマップが読み込み専用のRGB値をあらかじめ昇順で定義していることを除き,Direct color と同じである。True colorはDECの24プレーン・ システムにおける省略時のビジュアル・タイプである。
Static gray 読み込み専用 Static grayは白黒である。Static grayは,カラーマップ内の値が読み込み専用であることを除き,Gray scale と同じである。2項目のカラーマップをもつStatic gray は,モノクロと考えることができる。
Static color 読み込み専用 Static colorはフルカラーである。Static color は,読み込み専用でサーバ依存の値をカラーマップがあらかじめ定義している( 順序は定義せず,サーバに依存)ことを除き,Pseudocolorと同じである。


注意
システムによっては,1つのディスプレイで複数の画面をサポートできます。 各画面は様々な深さでサポートされている, いくつかの異なるビジュアル・タイプをもつことができます。Xlib は,クライアントがビジュアル情報のデータ構造体を使用することにより, システム上で適切なビジュアル・タイプを検索して選択できるルーチンを備えています。 詳しい説明は『VMS DECwindows Xlib Programming Volume』を参照してください。

DECburgerデモ用アプリケーションでは,例 10-2 に示すコードを使用して,アプリケーションがカラー画面に表示されているかどうかを確認するために,XVisual.class を検査します。DECburger はカラー画面だけのために,「背景色の設定」機能を実現しています。

例 10-2 XVisual.classの検査


   .

   .

   .

/* If it's a color display, map  customize color menu entry */

      if ((XDefaultVisualOfScreen(the_screen))->class == TrueColor

      ||  (XDefaultVisualOfScreen(the_screen))->class == PseudoColor

      ||  (XDefaultVisualOfScreen(the_screen))->class == DirectColor

      ||  (XDefaultVisualOfScreen(the_screen))->class == StaticColor)

        XtSetMappedWhenManaged(widget_array[k_custom_pdme], TRUE);

   .

   .

   .

10.4.1.1 書き込み可能なカラー・セル

カラー・セルにはビジュアル・タイプに応じて,読み込み専用と書き込み可能があります。 ディスプレイが読み込み専用のカラー・ セル(StaticGray,StaticColor,TrueColor)をもっていることをXVisual.class フィールドが示している場合に,読み込み/書き込み可能なカラー・ セルを割り当てようとすると,Xエラーが発生します。

アプリケーションはXAllocColorルーチンを呼び出して読み込み専用のカラー・ セルを割り当てるとき,使用したい色のRGB値を指定します。すると, サーバはすでに割り当てられている色を検索します。要求した色がすでに割り当てられている場合, そのピクセル値が返されます。まだ割り当てられてない場合は, 指定したRGB値,または指定したRGB値にもっとも近い値を格納するために, カラー・セルを割り当てます。XAllocColorは, XColor.pixelフィールドのカラー・セルを識別するピクセル値を返します。 アプリケーションはセルのRGB値を変更することはできません。


注意
XAllocColorルーチンはどのビジュアル・ タイプでも使用することができますが,Gray scaleまたはStatic gray のシステム上では,カラーのコントラストがない場合があります。

読み込み専用のカラー・セルは各クライアントで共用します。つまり,別のアプリケーションが同じRGB 値でXAllocColorを呼び出すと,カラー・セルを共用するアプリケーションにもピクセル値が返されます。 これはカラーマップの追加項目にはなりません。

読み込み/書き込み可能なカラー・セルの場合,セルのRGB初期値は定義されていません。RGB 値をセルに格納するために,アプリケーションはXStoreColor またはXStoreColorsを呼び出さなければなりません。読み込み/ 書き込み可能なセルは,セルのRGB値が変更される可能性があるので, 共用してはなりません。

10.4.1.2 ディスプレイの深さ

プログラマはディスプレイの深さ(プレーンの数)について仮定をしてはなりません。 たとえば,8プレーンが利用できると仮定してプログラムを作成した場合に, そのアプリケーションを4プレーンの画面に表示すると, 予測できない結果が発生します。

アプリケーションはXDefaultDepthofScreenルーチンまたはXPlanesofScreen ルーチンを呼び出して,画面でサポートされるプレーンの最大数を判断しなければなりません。

システムによっては,1つのディスプレイで複数の画面をサポートできます。 各画面は,さまざまな深さでサポートされる複数の異なるビジュアル・ タイプをもつことができます。

10.4.1.3 不十分なカラー資源の処理

カラー資源が限られているシステム上でアプリケーションを表示する場合には, 資源が不足する場合に対処できるようにしておかなければなりません。 たとえば,20のカラー・セルを割り当てたいが10のカラー・セルしか利用できない場合, アプリケーションはどのように処理するかを判断しなければなりません。

すべてのカラー・セルがなければアプリケーションが正しく機能しない場合は, 利用できるカラー資源が不十分なことを伝えるメッセージを表示して, アプリケーションを終了します。たとえばDECburgerデモ用アプリケーションでは, カラー・セルを割り当てることができない場合,例 10-3 に示すコードを使用して,メッセージを表示しアプリケーションを終了します。

例 10-3 カラー資源の確認


   if (XAllocColor(XtDisplay(toplevel_widget),

                  XDefaultColormapOfScreen(the_screen), &newcolor)) {



     ac = 0;

     XtSetArg (arglist[ac], XmNbackground, newcolor.pixel);ac++;

     XtSetValues(widget_array[k_total_order], arglist, ac);

     XtSetValues(main_window_widget, arglist, ac);

    }

   else

        s_error ("can't allocate color cell");



   .

   .

   .

static void s_error(problem_string)

    char *problem_string;

{

    printf("%s\n", problem_string);

    exit(0);

いくつかのカラー・セルを割り当てることによってアプリケーションが機能する場合は, 優先順位に従ってカラー・セルを割り当ててください。たとえば, 第10.4.1.3項で説明したように, さまざまなカラー・モデルでカラーを表示するために,Color Mixingウィジェットは29のカラー・セルを割り当てようとします。Color Mixingウィジェットはまず,一番重要なカラー・セルを割り当てます。29 のセルのすべてを割り当てることができない場合,Color Mixingウィジェットは必要に応じて機能をかすんで表示します。

10.5 イメージ・フォーマット

アプリケーションは,サーバが期待するフォーマットで,イメージ・データ( ビットマップ,ピックスマップ)をXサーバへ提示する必要があります。 フォーマットが異なるとエラーが発生します。このことは,異なるイメージ・ フォーマットを持つ複数のハードウェア・プラットホームにアプリケーションを表示する場合, 特に重要です。

たとえば,/usr/examples/motif/bitmap.exe(UNIX)あるいはDECW$EXAMPLES:BITMAP.EXE (OpenVMS)プログラムを使用して,次のビットマップを作成したと仮定します(ビットマップ例はWindows NT 用のeXcursion では提供されません)。


     #define icon_width 24

     #define icon_height 20

     static char icon_bits[] = {

        0x00, 0x00, 0x00, 0x00, 0x3c, 0x00, 0x00, 0x3c, 0x00, 0x00, 0x3c, 0x00,

        0x00, 0x3c, 0x00, 0x00, 0x3c, 0x00, 0x00, 0x3c, 0x00, 0xfe, 0xff, 0x7f,

        0xfe, 0xff, 0x7f, 0x0c, 0x00, 0x30, 0x18, 0x00, 0x18, 0x30, 0x00, 0x0c,

        0x60, 0x00, 0x06, 0xc0, 0x00, 0x03, 0x80, 0x81, 0x01, 0x00, 0xc3, 0x00,

        0x00, 0x66, 0x00, 0x00, 0x3c, 0x00, 0x00, 0x18, 0x00, 0x00, 0x00, 0x00};

たとえば,BITMAP.EXEはLSBFirstと等しいbyte_orderおよび bitmap_bit_orderでビットマップを作成します。このビットマップは,VAX のディスプレイ上ではイメージのデータとして使用できますが,PC サーバによっては表示するとエラーを発生することがあります。 複数のハードウェア・プラットホーム上でアプリケーションを表示する場合, イメージ・フォーマットにおけるこのような問題に対処しておく必要があります。

次の各節では,このイメージ・フォーマットの問題に対処する方法について説明します。

10.5.1 イメージ・フォーマットの実現

X11サーバとXlibは,プロトコルが要求する最大サイズ設定のためのプロトコル情報の交換や, プロトコル要求のためのバイト順序の設定などを行います。 サーバは,使用するイメージ・フォーマットの順序を含む,これらの接続パラメータのほとんどを決定します。

アプリケーションがサーバのイメージ・フォーマットを決定できるように,Xlib のXOpenDisplayルーチンは,サーバが提供する次のようなセットアップ・ パラメータをDisplayデータに設定します。

Displayフィールド 説明
byte_order イメージのバイト順序。許容値はLSBFirst ( 最下位バイトが左端)とMSBFirst (最上位バイトが左端) 。
bitmap_bit_order ビットマップのビット順序。 許容値はLSBFirst (最下位ビットが左端)とMSBFirst ( 最上位ビットが左端)。

XlibのXImageByteOrderルーチンおよびXBitmapBitOrderルーチンを使用すると, イメージのバイトとビットの順序を決定できます。

10.5.2 イメージ・フォーマットの決定

アプリケーションはイメージに使用するデータのbyte_ orderbitmap_bit_orderを,XCreateImageルーチンで指定することはできません。

そのため,アプリケーションは次のように機能する必要があります。

  1. XCreateImageを呼び出してイメージを作成する。すると, XImageデータ構造体が返される。

  2. XImage.byte_orderおよびXImage.bit_orderフィールドを, イメージに使用するデータのフォーマットに明示的に設定する。

  3. アプリケーションがXPutImageを呼び出してメモリ内のイメージと描画可能なイメージを組み合わせる場合,XPutImage はデータの byte_orderbitmap_bit_orderがサーバの期待するフォーマットと一致するかどうかを検査し, 一致しない場合にはデータをサーバのフォーマットに変更する。

    アプリケーションでbyte_orderbitmap_bit_orderのフィールドを明示的に設定しない場合,XPutImage はサーバの省略時のフォーマットを使用して, イメージに使用するデータのフォーマットは検査しないため, これがエラーの原因となる場合がある。


[ 前のページ ] [ 次のページ ] [ 目次 ] [ 索引 ]