共通デスクトップ環境には、コンポーネントおよび使用に関するガイドラインがあり、これに従うとデスクトップ上でアプリケーションを他のアプリケーションより高度なレベルで統合できます。この章では、アプリケーションとデスクトップとの一貫性のレベルを高めるために使用することを推奨するコンポーネントとガイドラインの概要を説明します。
コンポーネントの統合とこの節で説明するガイドラインの他に、第 5 章「基本的なアプリケーションの統合方法」で概説する基本的な統合方法も参照してください。
推奨する統合方法の詳細は、『Solaris 共通デスクトップ環境 プログラマーズ・ガイド』を参照してください。
共通デスクトップ環境のヘルプ・システムは、アプリケーション・ソフトウェアのオンライン・ヘルプを開発および表示するための完全なシステムです。これにより、設計者は豊富なグラフィックとテキスト・フォーマット、ハイパーリンクを備えたオンライン・ヘルプを書くことができ、アプリケーションからヘルプ・システムへアクセスできます。ヘルプ・システムはヘルプ機能をアプリケーションへ統合するためのプログラマのツールキットを提供します。
オンライン・ヘルプの作成とアプリケーションへの統合は、共同作業で行われます。ユーザのヘルプ要求にアプリケーションがどのように応答するかは、開発者が設計し実装します。設計者は、実際に表示されるヘルプ情報を構成し作成します。
ヘルプ・システムには次のものが含まれます。
共通デスクトップ環境のヘルプタグ・マークアップ言語
共通デスクトップ環境のヘルプタグ・ソフトウェア
ヘルプタグ・ファイルを実行時のヘルプ・ファイルに変換するためのソフトウェア・ツール・セット
共通デスクトップ環境のヘルプビュー・アプリケーション
オンライン・ヘルプを表示するためのビューア・プログラム
設計者はヘルプ・タグ・セットを使用し、Structured Graphic Markup Language (SGML) タグ規則に従ってヘルプ・トピックを作成します。SGML マークアップは一次データ・フォーマットです。コンパイルされた実行時のフォーマットは SGML に準拠します。
ヘルプ・システムは、UNIX マニュアル・ページ、テキスト・ファイル、テキスト文字列などの SGML でないフォーマットもサポートします。
DtHelp プログラミング・ライブラリ
ヘルプ・ウィンドウを作成してアプリケーションと統合するための アプリケーション・プログラム・インタフェース (API)
DtHelp ウィジェット
ヘルプ・ダイアログ・ボックスと簡易ヘルプ・ダイアログ・ボックス (いずれもヘルプ・ライブラリの一部) を作成するための DtHelpDialog および DtHelpQuickDialog ウィジェット
ヘルプ・ライブラリ libDtHelp は、Motif に基づくヘルプ・ダイアログの作成と管理をサポートします。libDtHelp ヘッダ・ファイルは次のとおりです。
Dt/Help.h
Dt/HelpDialog.h
Dt/HelpQuickD.h
/usr/dt/examples/dthelp にヘルプ・システム・デモがあります。デモの詳細は、 README ファイルを参照してください。
ヘルプ・システムの詳細は、関連するマニュアル・ページと『プログラマーズ・ガイド (ヘルプ・システム編)』を参照してください。
共通デスクトップ環境は、メッセージ・セットと呼ばれる 2 つの標準 ToolTalk プロトコルを定義します。メッセージ・セットは、送信側プロセスと処理側プロセスとで交換できるメッセージの集まりです。これらのメッセージは、関連する要求および通知を記述するものごとにグループ化されています。送信者および受信者は同じプロセスにあっても異なるホストにあってもかまいません。メッセージ・セットには、ローレベルの詳細に気をとられることなくプロトコルのセマンティクスだけに集中できるようにする関連ユーティリティ機能があります。機能の中には、簡単にデフォルト動作に従えるようにするものもあります。
デスクトップ・メッセージ・セットには次の 3 つの領域があります。
ウィンドウ動作
ファイル・アクセスおよびファイルの短期ライフサイクル制御
アプリケーション拡張言語
ウィンドウ動作の詳細は、「デスクトップの処理」および 「デスクトップの送信」の項を参照してください。ファイル・アクセスおよびファイルの短期ライフサイクル制御の詳細は、「デスクトップ・ファイル」の項を参照してください。Do_Command 要求の実装はアプリケーションの拡張言語に固有のもので、ToolTalk メッセージ・サービスではサポートしません。
メディア・メッセージ・セットにより、アプリケーションが、任意のメディアのコンテナまたはそのようなコンテナから起動できるメディア・プレイヤおよびエディタとなることができます。メディア・メッセージ・セットによって、コンテナ・アプリケーションは、該当するメディアの型のフォーマットを知らなくても任意のメディアのドキュメントを作成、表示、編集、印刷できます。ToolTalk メッセージ・サービスは、コンテナの要求を、指定されたメディアの型とオペレーション用のツールへ渡します。すでに実行中のツールのインスタンスがその要求を処理するのに最適であれば、そのインスタンスが要求されます。「メディアの送信」および 「メディアの処理」を参照してください。
ToolTalk メッセージ・サービスは次のようなメッセージ・セットをサポートします。
デスクトップ要求の処理は、メッセージング統合の中で最も基本的なものです。ToolTalk メッセージを送信するアプリケーションは、tt_message_send() または DtActionInvoke() のいずれを呼び出す場合も、デスクトップ要求を処理します。これによって、アプリケーションの現在のディレクトリ、アイコンの状態、$DISPLAY などを他のアプリケーションが設定または照会できます。詳細は、ttdt_open()、ttdt_session_join()、ttdt_session_quit()、 ttdt_close() のマニュアル・ページを参照してください。
アプリケーションを ttsession で起動し、ToolTalk 要求を処理するようにすると、このアプリケーションは要求送信者ではなく ttsession の子になります。アプリケーションは通常、送信者と同じ X の表示セッションで起動されますが、同じ X11 画面または同じ現在のディレクトリ・コンテキストにある必要はありません。アプリケーションがサーバ・プロセスとして実装された場合、すでに特定の画面または特定のディレクトリ・コンテキストに表示されています。
デスクトップ要求を使用すると、アプリケーションの操作は、デスクトップ以外でコマンド行の起動で継承される送信者の属性から継承できます。このようにデスクトップ・メッセージ・セットを使用し、ハンドラのロケール、現在の作業ディレクトリ、$DISPLAY をリセットしてください。これにより、入念にコード化された受信アプリケーションが送信者として同じ X11 画面に表示されます。要求ハンドラは要求送信者の現在のディレクトリとウィンドウのジオメトリを見つけることもできます。ウィンドウのジオメトリを知っていると、要求ハンドラのウィンドウが要求送信者のウィンドウをできる限り隠さないようにできます。詳細は、ttdt_sender_imprint_on() のマニュアル・ページを参照してください。
ToolTalk メッセージ・サービスは、エディタが処理するメディアの型に対する標準メディア要求を、処理しやすくします。詳細は次のマニュアル・ページを参照してください。
ttmedia_ptype_declare()、ttdt_message_accept()、 ttmedia_load_reply()、ttmedia_Deposit()
ToolTalk メッセージ・サービスは、コンテナのメディア要求送信と、ハンドラが返す一連のドキュメントの管理を容易にします。コンテナがメディア・ハンドラで 実行中の ToolTalk ダイアログを処理していない場合は、ToolTalk API を直接使用するのではなく、アクション API を使用してください。相当するアクション ([開く] と [印刷]) は、ToolTalk および ToolTalk 以外が検知するメディア・ハンドラと同等のハンドラをサポートする上位の概念を示します。詳細は、ttmedia_load() および ttdt_subcontract_manage() のマニュアル・ページを参照してください。ほとんどの場合、コンテナ・アプリケーションは ttmedia_load() ではなく DtActionInvoke() を使用してオブジェクトのオペレーションを実行するので注意してください。アクションによって ToolTalk アプリケーションを起動する方法の詳細は、『ToolTalk メッセージの概要』を参照してください。
ToolTalk メッセージ・サービスは、ファイルに関するデスクトップのメッセージを送受信しやすくします。これらのメッセージにより、アプリケーションがファイルへのアクセスを調整できるようになります。詳細は次のマニュアル・ページを参照してください。
ttdt_file_join()、ttdt_file_quit()、ttdt_file_event()、 ttdt_Get_Modified()、ttdt_Save()、ttdt_Revert()
ToolTalk メッセージ・サービスをすでに使用しているアプリケーションの例は、共通デスクトップ環境のアイコン・エディタ、メール・プログラム、テキスト・エディタ、カレンダなどです。共通デスクトップ環境の他の部分では、メッセージを送信するアクションを定義することにより、ToolTalk メッセージ・サービスを間接的に使用しています。
ToolTalk メッセージ・ライブラリは libtt と呼ばれます。libtt ヘッダ・ファイルは次のとおりです。
Tt/tt_c.h
Tt/tttk.h
ToolTalk メッセージ・サービスのデモは /usr/dt/examples/tt にあります。デモの詳細は README ファイルを参照してください。
ToolTalk メッセージ・サービスの詳細は、関連するマニュアル・ページと『ToolTalk メッセージの概要』を参照してください。
セッション・マネージャは ICCCM.1.1 WM_COMMAND および WM_SAVE_YOURSELF プロトコルをサポートし、次のことを許可します。
アプリケーションがログアウト時の状態情報を保存する
セッション・マネージャがログイン時にアプリケーションを再起動する
セッション・マネージャは API も提供し、アプリケーションがログアウト時およびログイン時の状態を保存および格納するのを補助します。
セッション・マネージャはログイン時のアプリケーション再起動に責任を持ちます。これを行うには、再起動に必要なコマンドおよびコマンド行オプションをアプリケーションがセッション・マネージャに通知しなければなりません。Xlib の XSetCommand() を使用して、アプリケーションのトップ・レベル・ウィンドウに WM_COMMAND 属性を設定してください。
セッション・マネージャがログアウト時などにセッションを保存する際に、アプリケーションは似たような状態での再開のために一部の状態情報を保存する必要があります。セッション・マネージャは、オプションでセッションが保存されていることをアプリケーションに通知します。このような通知が必要であることをアプリケーションはセッション・マネージャに知らせなければなりません。これは WM_SAVE_YOURSELF プロトコルをトップ・レベル・ウィンドウの WM_PROTOCOLS 属性に登録し、コールバック・プロシージャを設定して通知を処理します。これには XmAddWMProtocols() および XmAddWMProtocolsCallback() 関数を使用します。WM_SAVE_YOURSELF コールバックを処理しているときに何らかの方法でアプリケーションがユーザと対話すべきではありません (たとえば [別名保存] ダイアログ・ボックスは表示するべきではありません) 。このコールバックは WM_COMMAND 属性をトップレベル・ウィンドウに設定して、セッション・マネージャに状態の保存が終了していることを通知しなければなりません。
アプリケーションが状態情報を保存できるようにするには、DtSessionSavePath() 関数を使用して、情報を保存するファイルの絶対パス名を獲得してください。セッションの復元時は、DtSessionRestorePath() 関数を使用して、アプリケーションが状態を復元するのに使用する状態ファイルの絶対パス名を獲得してください。
共通デスクトップ環境のワークスペース・マネージャは、アプリケーションのメイン・トップレベル・ウィンドウ (WM_COMMAND を含む) 属性を正しいワークスペース、ジオメトリ、アイコン状態に復元します。アプリケーションに複数のトップ・レベル・ウィンドウがある場合、他の上位ウィンドウの状態の復元はアプリケーションが担当します。その他の情報については、「ワークスペース・マネージャ」を参照してください。
デスクトップ・ライブラリ libDtSvc は、セッション・マネージャも含めて多数のデスクトップ API へアクセスできるようにします。Dt/Dt.h および Dt/Session.h ヘッダ・ファイルを取り込んで、セッション・マネージャ API にアクセスしてください。
アプリケーションが任意のセッション・マネージャ API を使用している場合、まず DtInitialize() または DtAppInitialize() を呼び出して libDtSvc ライブラリを初期化しなければなりません。詳細は、DtInitialize(3) または DtAppInitialize(3) のマニュアル・ページを参照してください。
セッション・マネージャのデモは /usr/dt/examples/dtsession にあります。詳細は README ファイルを参照してください。
セッション・マネージャの詳細は、関連するマニュアル・ページと『Solaris 共通デスクトップ環境 プログラマーズ・ガイド』を参照してください。
共通デスクトップ環境は、 Motif 2.1 ドラッグ&ドロップ API の一番上のレイヤ上にドラッグ&ドロップ API を提供し、デスクトップにおいて便利で一貫した相互運用可能なドラッグ&ドロップ API をサポートします。共通デスクトップ環境ドラッグ&ドロップ API により、開発者はドラッグ&ドロップを容易に実現できます。ドラッグ&ドロップがあれば、ユーザはディスプレイ上でグラブしたり、ドラッグしたり、他のオブジェクトにドロップしてオブジェクトの場所の変更やデータ転送を行い、直接画面上でオブジェクトを処理できます。
Motif 2.1 ドラッグ&ドロップはローレベルの機能を提供し、共通デスクトップ環境ドラッグ&ドロップはこれらの機能のポリシーを取り込んでいます。
共通デスクトップ環境ドラッグ&ドロップは、API と、Motif ドラッグ&ドロップへのインタフェースを単純化するプロトコルから成ります。これはバッファ転送プロトコルやドラッグ・カーソルの形状などのポリシーを実現します。共通デスクトップ環境ドラッグ&ドロップ API を組み込みポリシーと共に使用して、一貫した相互運用性を保証してください。共通デスクトップ環境ドラッグ&ドロップ・ポリシーは、テキスト転送およびファイル名転送用の標準 Motif 2.1 ドラッグ&ドロップ・プロトコルと互換性があります。
共通デスクトップ環境ドラッグ&ドロップは、データを転送するのに X 選択機能を使用します。適切なターゲットはすでに存在し、X コンソーシアムに登録されています。2 つのデスクトップ・アプリケーションは、テキスト、ファイル名、データの転送プロトコルによってデータを転送します。
既存のドラッグ&ドロップのための Motif 2.1 API は柔軟性があり、したがって熟練していない開発者には使用するのが幾分難しいところがあります。共通デスクトップ環境ドラッグ&ドロップ API は、API を単純で簡単に使用できるよういくつかの便利な機能を提供しています。
ドラッグ・アイコンの構成と形状を管理します。
共通デスクトップ環境ドラッグ&ドロップには、Motif 2.1 のドラッグ・アイコンを作成するデフォルトのソース、状態、操作アイコンのグラフィックがあります。
バッファ転送プロトコルを定義します。
Motif 2.1 ドラッグ&ドロップはファイル名とテキスト文字列だけのプロトコルを定義します。
ドロップにおけるアニメーションを可能にします。
ドロップを完了したときに呼び出されるアニメーション手続きをドロップ領域が定義できます。
TEXT および FILE_NAME 転送のターゲットを列挙します。
重複して登録できます。
テキスト・ウィジェットをテキスト以外のデータ用にドロップ領域として登録しながら、テキストのドロップを受け入れる機能も残しておくことができます。
優先順位の付いたドロップ・フォーマットを提供します。
ドロップ領域でプロトコルを指定した順に優先順位が付けられます。
デスクトップ・サービス・ライブラリ libDtSvc は、ドラッグ&ドロップも含めたあらゆるデスクトップ API へのアクセスを提供します。ドラッグ&ドロップ API をアクセスするには、Dt/Dt.h および Dt/Dnd.h ヘッダ・ファイルを取り込んでください。
アプリケーションが任意のドラッグ&ドロップ API を使用している場合、まず DtInitialize() または DtAppInitialize() を呼び出して libDtSvc ライブラリを初期化してください。詳細は、DtInitialize(3) または DtAppInitialize(3) のマニュアル・ページを参照してください。
ドラッグ&ドロップのデモは /usr/dt/examples/dtdnd にあります。詳細は README ファイルを参照してください。
共通デスクトップ環境ドラッグ&ドロップの詳細は、関連するマニュアル・ページと『Solaris 共通デスクトップ環境 プログラマーズ・ガイド』を参照してください。
共通デスクトップ環境は 1 バイトおよびマルチバイトのロケールをサポートするよう国際化対応しています。開発者は、任意の共通デスクトップ環境プラットフォームで実行するため簡単にローカライズできる、国際化対応アプリケーションを作成できます。
共通デスクトップ環境アプリケーション (ソースおよびバイナリの両方) は、いろいろな言語および地域にローカライズでき、複数のベンダおよびハードウェア・プラットフォームで使用できます。
ラテン・アメリカ
西ヨーロッパ
日本
韓国
中国 (繁体字と簡体字)
タイ語
ヘブライ語
アラビア語
共通デスクトップ環境は次のような標準で国際化対応機能を使用します。
アプリケーションを国際化対応させる場合、マルチバイト文字の入出力をサポートしていることを確認してください。また、メッセージ・カタログを使用していてコードを完全にローカライズできることも確認してください。
/usr/dt/examples/template にある描画プログラムのデモは国際化されています。詳細は README ファイルを参照してください。
共通デスクトップ環境国際化対応の詳細は、開発環境コンポーネントのマニュアル・ページと『プログラマーズ・ガイド (国際化対応編)』を参照してください。
共通デスクトップ環境で定義された標準フォント名は、すべての共通デスクトップ環境準拠システムで使用できることが保証されています。これらは実際のフォントを示すものではありません。各システムのベンダが最も適切に使用できるフォントにマップするための別名です。アプリケーションでこのフォント名のみを使用していれば、任意の共通デスクトップ環境準拠システムで最も近いフォントを使用できます。これには、最も一般的な設計および形式で使用できる X Window System のフォント名を含みます。
標準フォント名は、別の共通デスクトップ環境プラットフォームでは、通常 X のフォント別名機能によって別のフォントにマップされます。これによって異なるプラットフォーム上のさまざまなフォントから選択しなければならないという問題から解放されます。また、特定のベンダの共通デスクトップ環境の実装でデフォルトのフォント・セットを使用できるようになります。
共通デスクトップ環境は 2 種類の標準フォントを定義します。アプリケーション・フォントとインタフェース・フォントです。アプリケーション・フォントをアプリケーションからの出力に使用してください。Motif ウィジェットおよびデスクトップではインタフェース・フォントを使用します。このデフォルト・フォントは変更しないでください。
すべての共通デスクトップ環境プラットフォームで、最小 6 種類のフォントサイズが使用できます。各フォントは、標準フォント名 8、10、12、14、16、18、24 に関連しています。共通デスクトップ環境用 XLFD フォントの記述は次のようになります。
-dt-application-*
上記のようなパターンを使用すれば有効です。
テキストの表示に使用されるフォントのデザインのバリエーションで最も一般的なのは、serif と sans serif 、およびプロポーショナルと固定幅文字の選択です。これら 2 つのデザインのバリエーションを組み合わせると、次の 4 つのデザインがあります。
serif でプロポーショナル
sans serif でプロポーショナル
serif で固定幅
sans serif で固定幅
上記 4 つのデザインの一般例は次のとおりです (順序は上記のとおりです)。
Times Roman (タイムズ・ローマン)
Helvetica (ヘルベチカ)
Courier (クーリエ)
Lucida Typewriter (ルシダ・タイプライタ)
これらのデザインには、(太さと傾斜の組合せによる) 次のような 4 つのスタイルがあります。
Plain (プレーン)
Bold (ボールド)
Italic (イタリック)
Bold-Italic (ボールド・イタリック)
上記 4 つのスタイルにはそれぞれ 4 つのデザインのバリエーションがあるので、合計 16 種類のフォントが生成されます。この 16 種類のフォントは一般のデスクトップ・コンピューティングで最も一般的に使用されるものです。たとえば Times Roman (タイムズ・ローマン)、Helvetica (ヘルベチカ)、Courier (クーリエ) は 4 つのスタイルにありますが、シンボル・フォントと共に Adobe 13、つまりすべての PostScript プリンタに組み込まれるフォントの最小セットを構成します。
アプリケーションは、正式なフォント・ファミリまたはフォント名を必要としませんが、たとえば固定幅フォント、sans serif フォント、serif フォントなどの使用は必要です。特定の共通デスクトップ環境プラットフォームに存在する正式フォント名を知る必要はありません。共通デスクトップ環境標準フォントは、ベンダのプラットフォームで最適な特定のデザインの選択をデフォルトにしています。
アプリケーションが必要とするフォントのリソース値として、アプリケーションの app-defaults ファイルでは概要アプリケーション・フォントの XLFD フォント名を指定して下さい。このフォント名を使用しない場合は、各共通デスクトップ環境プラットフォーム上の各アプリケーションに対して、別の app-defaults ファイルを提供する必要があります。
インタフェース・フォントは、特定のプラットフォームでデスクトップの外観を定義するのに最適化されたフォントの小さなセットです。これらのフォントはウィンドウ・タイトル、ボタン、メニュー、テキスト・フィールドなどに表示されている様に、少量の情報を明確にすばやく伝達します。
標準デスクトップおよび Motif ツールキット・ウィジェットはインタフェース・フォントを使用します。これらのフォントは、アプリケーション・ウィンドウ内で直接使用しないでください。
標準インタフェース・フォント名は標準アプリケーション・フォント名とは異なります。これはアプリケーション・フォント名のように、別の共通デスクトップ環境プラットフォーム上では、別のフォントにマップされます。インタフェース・フォントには次の 3 つのスタイルがあります。
System
読み専用テキスト (メニュー、ボタン、ラベルなど、限られた量のテキストに使用)
User
エンド・ユーザが入力したテキスト、または XmText 型および DtTerm 型のウィジェットから構築されるオブジェクトに示されるテキスト
User bold
ユーザ・フォントと同じで、ボールド
上記のスタイルサイズには 7 種類のサイズがあります。スタイル・マネージャを使用して、ユーザがデスクトップで使用するインタフェース・フォントのサイズを選択することもできます。
/usr/dt/examples/template にある描画プログラムのデモは、独自のインタフェース・フォントを指定しません。共通デスクトップ環境 Motif インタフェース・フォントの表示例を示します。ただし、このデモでは、アプリケーション・フォントは利用していません。
標準フォントの詳細は、関連するマニュアル・ページ、特に DtStdAppFontNames(5) および DtStdInterfaceFontNames(5) の XLFD フォント名のリストに関する記述と、『Solaris 共通デスクトップ環境 プログラマーズ・ガイド』を参照してください。
共通デスクトップ環境のアプリケーションは、共通モデルに従ってエラー・メッセージと警告を表示します。アプリケーションを実行しているユーザは、メッセージがメッセージ・フッタ、エラー・ダイアログ・ボックス、警告ダイアログ・ボックスのいずれかに表示され、詳細な記述は適切にオンライン・ヘルプに示されると思っています。
この節では、アプリケーションのエラー・メッセージの表示規則を概説します。メッセージ・テキストの処理方法ですので、エラー表示のガイドラインには正確に従ってください。たとえばフロントパネルからアプリケーションを起動すると、ユーザは標準エラーまたは標準出力に送信されるメッセージを見ることができません。共通デスクトップ環境では、そのようなメッセージは多くのユーザが定期的に調べないようなログ・ファイル ($HOME/.dt/*log) に出力されます。
ユーザに警告、メッセージ、エラー状態を通知する場所を決定するときは、次の規則に従ってください。
情報を示すメッセージの場合は、アプリケーションのメッセージ・フッタにテキストを表示する (例:「MyDoc ファイルをコピーしました。」)
エラーまたは重大な警告についてのメッセージの場合は (ユーザにとって重要な操作が失敗した場合のトラブルなど)、エラー・ダイアログ・ボックスまたは警告ダイアログ・ボックスに表示する
エラー・ダイアログまたは警告ダイアログは、ユーザに次のような情報を示す必要があります。
何が起こったか (ユーザの見地から)
なぜ起こったかをわかりやすく
問題の解決方法
追加のバックグラウンド情報が必要な場合、またはエラーを完全に説明するのに 4、5 行以上のダイアログが必要な場合は、ユーザを適切なオンライン・ヘルプのセクションに導くボタンを追加してください。
アプリケーションにおけるエラー・メッセージの表示、およびメッセージ・ダイアログのオンライン・ヘルプへのリンクの詳細は、『Solaris 共通デスクトップ環境 プログラマーズ・ガイド』を参照してください。
この節では、アプリケーションのユーザ・インタフェースを設計するときのガイドラインを示します。
アプリケーションのユーザ・インタフェースを設計するときは、共通デスクトップ環境が Motif およびデスクトップ・ウィジェットに提供するデフォルトのカラー・スキーマを無効にするようなカラーを設定しないでください。アプリケーション定義のカラーについては、次のカラーを使用して他のデスクトップ・アプリケーションとの共用を促進してください。
黒
白
赤
緑
青
黄
シアン
マゼンタ
グレー (濃淡は #e1、#c8、#af、#96、#7d、#64、#4b、#32 の 8 段階)
普通はカラーを指定する必要がなく、デスクトップのスタイル・マネージャでエンド・ユーザが選択したカラーを使用します。
Motif ウィジェットでは、共通デスクトップ環境が提供するフォントを使用し、アプリケーションのウィンドウが他のデスクトップ・クライアントのウィンドウと同じようになるように、またユーザがスタイル・マネージャを使用してこれらのフォントのサイズを変更できるようにしてください。提供されたフォントを、Motif fontList リソース仕様を変更して無効にする場合は、ユーザがアプリケーションでフォントをカスタマイズできるようにさせたければ、その機能を追加しなければなりません。
共通デスクトップ環境標準アプリケーション・フォント名にあるフォントを使用して、(Motif がウィジェット用に使用しているのとは別の) アプリケーションで使用する、app-defaults ファイルのリソースを指定してください。これは、アプリケーションがすべての共通デスクトップ環境プラットフォームで適切なフォントを見つけ、プラットフォーム上への移植性が高まることを保証します。詳細は、「標準フォント名」を参照してください。
スタイル・マネージャは、Motif バージョン 1.2 以降を使用して書かれたアプリケーションのフォントしか管理しません。Motif 1.1 (以前) のアプリケーションにはフォントは正しく提供されません。これらのアプリケーションには app-defaults ファイルで独自のフォントを指定してください。
この節では、ソフトウェア・アプリケーションを障害者が使用できるようにするためのガイドラインを示します。
通常はメニューやドラッグ&ドロップなどで操作するアプリケーションの全機能を、キーボードで操作できるようにし、身体的に障害のある人々が容易にアプリケーションを使用できるようにしてください。
視覚障害を持つ人がアプリケーションによりアクセスしやすくするために、次のガイドラインに従ってください。
アプリケーションのカラーをハードコードしないでください。
線、ボーダ、シャドウの厚みなどグラフィック属性をハードコードしないでください。これらの属性はフォント・サイズによって大きさが調整されます。
フォント・サイズおよびスタイルをハードコードしないでください。
すべてのウィジェットに記述名を付けてください。特に、パレット項目やアイコンなど画面のラベルに表示されないウィジェットについては、アプリケーション・コードで記述名を入れてください。これによって画面読み込みソフトウェアが記述情報を目の不自由なユーザにも提供できます。
聴覚障害を持つ人がアプリケーションによりアクセスしやすくするために、次のガイドラインに従ってください。
すべてのエンド・ユーザは音による通知が聞こえると想定しないでください。
適宜、エンド・ユーザが情報を得る方法を耳による合図と目による合図と選択できるようにしてください。
情報の取得方法を、聴覚によるものだけに依存しないようにしてください。
聴覚による情報取得を行う場合の周波数とボリュームを、エンド・ユーザが調整できるようにしてください。
視覚、聴覚、身体的な障害に関するガイドラインは、言語、知覚、その他に障害のあるエンド・ユーザにとって役立つものです。可能な限りティアオフ・メニューやユーザ構成のメニューなどの重要なアプリケーションの機能を取り込んでください。
エンド・ユーザにとってのアプリケーション間の一貫性を保つために、アプリケーションまたは app-defaults ファイルにダブルクリックの間隔をハードコードしないで下さい。ユーザがスタイル・マネージャでダブルクリック時間を変更すると、アプリケーションは他のデスクトップ・アプリケーションと同様にその変更に従います。
/usr/dt/examples/template にある描画プログラムのデモは、共通デスクトップ環境のデフォルトのカラーとフォントを使用します。このため、ユーザはスタイル・マネージャを使用し、このプログラムのカラーとフォントをカスタマイズできます。詳細は README ファイルを参照してください。
カスタマイズの問題の詳細は、『共通デスクトップ環境 スタイル・ガイド』を参照してください。