test

共通デスクトップ環境 プログラマ概要

第 4 章 移植性と保守性

この章では、移植性の高いアプリケーションを書くために、およびアプリケーションが共通デスクトップ環境の今後のリリースと互換性があることを保証するために使用できる情報を示します。

移植性の問題

この節では、共通デスクトップ環境をサポートする、異なるプラットフォーム間でのアプリケーションの移植性に関する問題を説明します。

標準

アプリケーションを共通デスクトップ環境に準拠させるには、Motif 2.1、ANSI-C、X11R6 標準に従わなければなりません。C++ でアプリケーションを開発する場合は、C++ バージョン 2.0 以降を使用してください。共通デスクトップ環境のアプリケーションを作成するとき、POSIX など他の標準に固執することはありません。デスクトップのアプリケーション・プログラム・インタフェース (API) を使用するアプリケーションは、他の共通デスクトップ環境プラットフォームへ移植できます。しかし、POSIX を使用するとソフトウェアの移植性は拡張されます。

ここで言う POSIX 標準は、IEEE Std 1003.1-1990 、『IEEE Standard for Information Technology−Portable Operating System Interface (POSIX)−Part 1: System Application Program Interface (API) [C Language], ISBN 1-55937-061-0』を指します。

また Motif 1.2 標準は、IEEE Std 1295、『Standard for Information Technology−X Window System Graphical User Interface−Modular Toolkit Environment』を指します。

上記 2 点の注文方法については、「関連マニュアル」を参照してください。

Makefile

X11R6 など、共通デスクトップ環境が依存しているライブラリは、プラットフォームが異なれば別の場所にインストールされていることがよくあります。これを解決するには、プラットフォーム固有のリファレンスを取り込むか、各プラットフォーム別の makefile を書いてください。

また、make プログラムの機能はプラットフォームによって異なります。アプリケーションに対して makefile を 1 つだけしか書かないのであれば、プログラムの移動先であるプラットフォームが使用している共通の make 機能を使用してください。プラットフォーム固有の make 機能は使用しないでください。

デスクトップと統合するのに、共通デスクトップ環境では定義された定数 (-D パラメータなど) を追加する必要はありません。POSIX などの標準に従う場合は、標準固有のフラグを追加してコンパイルする必要があります。特殊なコンパイラ要件があるかどうかについては、標準のドキュメントを参照してください。

/usr/dt/examples の各サブディレクトリには、異なるプラットフォーム用の makefile の例が入っています。これらの makefile はシステムの相違点を考慮しています。特に、一般的な makefile の例については、/usr/dt/examples/dtdts ディレクトリを参照してください。

コンパイル・オプション

アプリケーションがデスクトップの include ファイルを検索できるようにするには、次の行を各 makefile のコンパイル行に追加してください。

-I/usr/dt/include

リンク・オプション

アプリケーションがデスクトップ・ライブラリを参照できるようにするには、次の行を各 makefile のリンク行に追加してください。

-L/usr/dt/lib -l<libname1> -l<libname2>...

libname1、libname2 はアプリケーションが参照するライブラリ名です。デスクトップ・ライブラリ名は必要なだけ指定できます。次に例を示します。 

-L/usr/dt/lib -lDtSvc -ltt -lXm

このように指定すると、アプリケーションはデスクトップ・サービス、ToolTalk メッセージ・システム、Motif 1.2 ライブラリを参照します。

ファイル命名規則

アプリケーション・ファイル名とアプリケーションが生成するファイル名は、14 文字以内にしてください。そうすれば、長いファイル名をサポートしていないプラットフォームに移植できるようになります。この制限を持つプラットフォームがいくつかあります。

エンド・ユーザが生成するファイル名にはこの制限は当てはまりません。

ディスプレイ・サポート

アプリケーションは次のようなディスプレイ・オプションと構成をサポートする必要があります。

カラー・アイコンを作成するためにアイコン・エディタを使用すると、より容易にアプリケーションが他のデスクトップ・アプリケーションとカラーを共有できます。これにより、疑似カラー・ディスプレイで実行するときにカラー・セルの浪費を防ぎます。

共通デスクトップ環境の Motif ウィジェット・バイナリの互換性のガイドライン

すでにサブクラス化したウィジェットのデータ構造体サイズに依存する標準 Xt API を使用して実装するウィジェット・サブクラスは、Motif または共通デスクトップ環境の新バージョンとの互換性がない可能性があります。Motif の新バージョンのスーパークラスに新規フィールドが追加されている可能性があるからです。たとえば Motif 2.0 の XmManager および XmPrimitive クラスに新規フィールドが追加されています。

サブクラスは、ウィジェット・インスタンスの開始アドレスに関連して指定されたインスタンス・フィールドに対するコンパイルされたリファレンスを持つので、非互換が起こります。スーパークラス・インスタンス構造体を拡張したウィジェットを持つ新しい Motif ライブラリをインストールした場合に、コンパイルされたリファレンスは間違ったメモリの場所を指します。

このような問題を避けるため、Motif にはリソースを定義する機能と、インスタンスおよびウィジェットの全構造体の代わりにウィジェットの部分構造体の先頭 (アドレス) に関連する制約構造体にあるすべてのフィールドを参照できるようにするウィジェット・フィールドへアクセスする機能があります (ウィジェットの全構造体は、スーパークラス部分構造体を含みます) 。ウィジェット・クラスを最初に初期化したとき、この機能はこれらの関連するリファレンスを実行時に解決します。そのため、現在リンクされている Motif ライブラリから読み取る、ウィジェットのスーパークラス・インスタンス構造体のサイズを計算に入れます。

注 -

サブクラス化を実装する場合、アプリケーションと共通デスクトップ環境の今後のリリースとのバイナリ互換可能なものにするには、必ず Motif リファレンスの解決機能を使用してください。

この Motif 機能に関する詳細は、Motif 1.2 の XmResolvePartOffsets(3x) および XmResolveAllPartOffsets(3x) のマニュアル・ページと、『Motif 2.1 Programmer's Reference』を参照してください。ソースコード例は /usr/dt/examples/motif/dogs にあります。