test

Solaris 共通デスクトップ環境 Motif への移行

第 6 章 移植に関する問題とその対策

この章では、Solaris CDE デスクトップ上での OPEN LOOK アプリケーションの Solaris Motif への移植について説明します。この章に掲載されている情報のほとんどは、OPEN LOOK から OpenWindows デスクトップ上で動作する Motif への移植作業にも当てはまります。

移行の要素

OPEN LOOK ユーザインタフェースから Motif に移行する作業は複雑です。通常は、ウィジェットを 1 対 1 でスワップするわけにはいきません。コードを 1 行ずつ変換するような単純な作業であるとは期待しないでください。移行作業はアプリケーションによってさまざまで、アーキテクチャに大きな影響を与えるものからウィジェットが少々異なる程度のものまであります。

Solaris CDE デスクトップに移植することは、OPEN LOOK ユーザインタフェースを Motif に移行するだけでなく、アプリケーションに使用可能な Solaris CDE 開発環境の基盤をもつことを意味します。これらの機能の概要については、第 4 章「開発環境の移行に関する問題」を参照してください。開発環境のコンポーネントとマニュアルの詳細は、『共通デスクトップ環境 プログラマ概要』を参照してください。

移植の必要があるかどうか

まず、アプリケーションを本当に移植する必要があるかどうかを判断する必要があります。「既存のアプリケーションを Solaris CDE デスクトップ上で実行する」で説明したように、OPEN LOOK と Motif のアプリケーションは Solaris CDE デスクトップ上で「そのままの状態」で動作します。したがって、Solaris CDE デスクトップ上で動作させるために、既存のアプリケーションを Motif や CDE に移植する必要はありません。

このため、いつ、どんなときにアプリケーションを移植するかを柔軟に判断できます。たとえば、アプリケーションを Solaris CDE デスクトップに移植するのを、手持ちの製品の主要リリースまで待つと決めることもできます。

基本的な統合

基本的なアプリケーションの統合は、アプリケーションを Solaris CDE デスクトップに統合する場合に実行することを強くお勧めする作業です。これらの作業では、アプリケーションのソースコードを変更する必要はありません (ある種の印刷機能を統合してアプリケーション内で印刷可能にするには、コードを少し変更する必要がありますが、基本的な統合の場合はこの作業は省略可能です)。

基本的な統合の場合は、デスクトップのアプリケーションプログラムインタフェース (API) を広範囲に使用していません。したがって、ドラッグ＆ドロップ機能などのように、デスクトップとその他の対話を行うことはできません。

アプリケーションを Solaris CDE デスクトップに統合するためにコードを変更しなくても、次のさまざまな作業を実行できます。

Solaris CDE デスクトップは、アプリケーションと他のデスクトップアプリケーションとの相互運用性を提供します。新しいサービスを使用する場合は、コードを変更すれば追加できます (「推奨する統合」と 「オプションの統合」を参照してください)。

アプリケーション内で印刷可能にする方法と、基本的な統合の手順のリストについては、『Solaris 共通デスクトップ環境 プログラマーズ・ガイド』を参照してください。基本的な統合の手順を実装する方法については、『Solaris 共通デスクトップ環境 上級ユーザ及びシステム管理者ガイド』を参照してください。

移植を決定した場合

移植作業を実行してくれるツールはなく、常に従うべき絶対確実なアルゴリズムもありません。移植作業では、Motif と CDE について学習し CDE スタイルガイドラインを理解することが重要です。

移植の利点

CDE デスクトップに移植すると、次の利点があります。

Solaris CDE 環境に統合する

推奨する統合とオプションの統合では、コードを変更して、これらのカテゴリに含まれる機能を実装する必要があります。多数の CDE 機能を採用するほど、アプリケーションはデスクトップとさらに統合されます。

推奨する統合

Solaris CDE 開発環境には、デスクトップ上でアプリケーションを他のアプリケーションと適正に統合できるように、次のコンポーネントとガイドラインが含まれています。

オプションの統合

次の Solaris CDE コンポーネントを使用すると、デスクトップから提供されるサービスを強化して特殊なタスクを実行できます。

小さい事柄から始める

アプリケーションを Solaris CDE デスクトップに移植する計画を立てている場合、または移植の練習をする場合は、小規模な例から始めて段階的に作業を進めてください。

変換と配置

単純な GUI を持つ小型アプリケーションの場合は、2 段階のプロセスを使用して移植できます。

単純な OPEN LOOK アプリケーションと、このプロセスの具体例については、第 7 章「移植例: OPEN LOOK から Solaris Motif へ」を参照してください。

注 -

この方法は、大型アプリケーションを移植する場合にはお勧めできません。

Motif GUI ビルダを使用する

アプリケーションビルダ (以降、AppBuilder とします) または Visual WorkShop(TM) のような Motif GUI ビルダを使用すると、アプリケーション用に新しい Motif GUI を構築できます。「変換と配置」で説明した 2 段階のプロセスを使用してポートを移植する場合は、一度試してみてから変更を加えるという柔軟な対応が必要です。特定の GUI 内で手動でコーディングする場合は、変更するのが難しく時間がかかります。AppBuilder を使用すると、オブジェクトをドラッグ＆ドロップしてプロトタイプ GUI を簡単に作成できるので柔軟に対応できます。通常は、GUI ビルダを使用して新しい Motif インタフェースをレイアウトする方が、GUI を手作業で移植するよりも時間がかかりません。

実際には、使用する移植プロセスの種類やアプリケーションの大きさに関わらず、Motif GUI ビルダの使用を検討する必要があります。ビルダは GUI とアプリケーションのフレームワークコードをすべて生成するので、アプリケーションコードに専念できます。

アーキテクチャの影響

コードをすぐに Solaris Motif に変換しないでください。まずアプリケーションのアーキテクチャを調べてから、アプリケーションを Motif と CDE に移植してください。

アプリケーションのアーキテクチャが大きいほど、アプリケーションを正しく構成し直す作業は重要になります。このような場合に「変換と配置」戦略を使用すると、移植プロセスがさらに複雑になります。

GUI と内部

重要な機能が周辺の GUI から分離されているプログラムの場合は、OPEN LOOK ユーザインタフェースと Motif との違いが及ぼす影響を無視してもかまいません。しかし、コードがユーザのアクションにリンクされている場合や、OPEN LOOK の特定の機能に依存している場合は、それと同等の Solaris Motif 機能を作成するのが難しい場合があります。

コードモジュールを介して線を描画して、ユーザインタフェースを構成する部分をアプリケーションの残りの部分を構成する部分から完全に分離できる場合は、ユーザインタフェースモジュールを Motif 用に開発されたものと同等のモジュールに置き換えるプロセスに移行作業を集中できます。多くのアプリケーション開発者は、この種の明確な分離が必要なソフトウェア開発方式に従っており、ユーザインタフェースとアプリケーション内部の間でプログラムの境界を正式に指定している場合もあります。

また、ソフトウェアがよりモノリシックで 、ユーザインタフェースを提供する機能にアプリケーション固有の機能が埋め込まれている場合は、この 2 つのタイプの機能を分離するのに膨大な時間が必要になるため移行作業は複雑になります。極端な場合には、スタイルガイドに違反するか、プログラムの一部を設計変更するかを選択しなければなりません。

Solaris CDE ソフトウェアの持つすべての機能を活用するための所要時間は、アプリケーションの配置に大きく左右されます。適切に設計されたアプリケーションほど簡単に移植でき、保守しやすく読みやすいように適切に分割できます。

静的配置と動的配置

前述のように、アプリケーションを Motif に移植する作業は、オブジェクトごとにスワップするわけではありません。このようなスワップは、アプリケーションユーザインタフェースの静的面に集中しています。特に、複雑なアプリケーションには、アプリケーションの基盤を管理する多数のオブジェクトが入っており、基盤を動的な状況で機能させます (アプリケーションの動的面には、ウィンドウのサイズ変更、ローカリゼーション、フォントの変更などが含まれますが、他の要素も含まれます)。OPEN LOOK と Motif のツールキットでは、アプリケーション内の動的ジオメトリを処理するこれらの「マネージャウィジェット」が異なります。マネージャウィジェットをオブジェクトごとにスワップしようとすると、アプリケーションは希望どおりの動的面を示しません。通常、アプリケーションの動的面の処理に適した設計を導入すると、アーキテクチャはより複雑になります。

XView では、多様な動的配置は使用できません。主として、オブジェクトは位置 (x,y) で固定されているため、アプリケーションフォントの変更や、アプリケーションの言語対応化は難しい場合があります。Motif と OLIT には、多様なジオメトリマネージャウィジェットがありますが、両者は大きく異なります。

表 6-1 OLIT と Motif のジオメトリマネージャウィジェット

OLIT 

Motif 

コメント 

BulletinBoard

XmBulletinBoard

基本的には同等。子を静的な x,y ピクセルベースで配置できます。 

Caption

(なし) 

OLIT の Caption ウィジェットを使用すると、コントロールウィジェットの 4 面のいずれかにラベルを自動的に配置できます。

この機能を Motif に導入するには、ラベルとコントロールという 2 つの子が入った別の XmRowColumn ウィジェットを作成します。

ControlArea

XmRowColumn

どちらのウィジェットを使用しても、行と列で子を配置できます。OLIT の ControlArea ウィジェットは、コロンを使用した Caption ウィジェットの子の垂直整列をサポートしています。これは、Motif の XmRowColumn ウィジェットにはない機能です。1

Motif の XmRowColumn ウィジェットは、特定のサイズポリシー (通常は、特定の行または列内の子を同じサイズにする) を子に適用しますが、OLIT の ControlArea ウィジェットにはこの機能はありません。

FooterPanel

(なし) 

OLIT の FooterPanel ウィジェットを使用すると、最下部にフローティングフッタの子が付いたウィンドウを配置できます。

フッタとして使用できるウィジェット (XmForm または XmRowColumn ウィジェットなど) として「メッセージ領域の子」を設定すると、Motif の XmMainWindow ウィジェットをこの配置用に構成できます。

Form

XmForm

どちらのウィジェットを使用しても、その子を相互に相対的に接続し Form 自体に相対的に接続できますが、これらの「アタッチメント」の表示はそれぞれ異なります。OLIT の Form ウィジェットは x 軸と y 軸のアタッチメントリソースを提供しますが、Motif の XmForm ウィジェットは 4 面 (上下左右) すべてに別のアタッチメントを提供します。両方のアタッチメントパラダイムがよくわかっている場合は、OLIT の Form ウィジェットアタッチメントを同等の XmForm ウィジェットアタッチメントに変換できます。Motif の XmForm ウィジェットは、「Position」という特殊なアタッチメントタイプも提供します。Form ウィジェットのサイズが変化するたびに変化する Form ウィジェット内の動的位置に子を接続できます。これにより、Form ウィジェットの占有部分に常に一定のパーセントを占めるように子を構成できます。

RubberTile

(なし) 

OLIT の RubberTile ウィジェットは、RubberTile ウィジェットの高さ (垂直方向の場合) または幅 (水平方向の場合) に一定のパーセントを占めるように子を構成できます。

Motif では、XmForm ウィジェット内で Position ベースのアタッチメントリソースを使用すると、同様の機能を得られます。

ScrolledWindow

XmScrolledWindow

どちらのウィジェットを使用しても、子ウィジェットをスクロール可能な表示ポートに含むことができます。 

(なし) 

XmMainWindow

Motif の XmMainWindow ウィジェットは、子をウィンドウの特定の領域に配置するマネージャを提供します。これらの領域には、メニューバー領域、コマンド領域、作業領域、メッセージ領域が含まれます。

OLIT には、同等のウィジェットはありません。 

(なし) 

XmPanedWindow

Motif の XmPanedWindow ウィジェットを使用すると、子を垂直方向の区画内に配置できます。各区画には、垂直方向にサイズ変更できるサッシが付いています。

OLIT には、同等のウィジェットはありません。 

  1. CDE の AppBuilder は、コロンで垂直に整列させるなど、ウィジェットを共通の位置に自動的に配置できる「グループ」というジオメトリマネージャ抽象化を提供します。この機能を実装するために、AppBuilder はすべてのコードを生成します。

ターゲット環境を学習する

CDE デスクトップは OpenWindows デスクトップとはまったく異なりますが、同じタイプのツールが多数入っています。最も明らかな違いは、CDE デスクトップは Motif デスクトップであることです。エンドユーザ環境と開発環境のアーキテクチャ構造の詳細は、『共通デスクトップ環境 プログラマ概要』を参照してください。また、次のマニュアルも参照してください。

GUI 開発ツール

Motif GUI ビルダを使用してアプリケーションの GUI を作成した場合は、Solaris CDE デスクトップに簡単に移行できるはずです。ほとんどの場合、ビルダを使用するとユーザインタフェースの関数とアプリケーションの内部関数をある程度分離することになります。その長所については前述のとおりです。

通常、ビルダは汎用内部記憶形式を使用するか、相互交換ファイルを生成する機能があり、各ファイルは変換プロセスの一部を自動化するために後処理できます。ビルダのベンダーに、現在どんな移行ツールを販売しているか問い合わせてください。

その他にあまり確立されていないものの移行作業を容易にするようなツールには、機能要件に関する文書や高水準の設計を生成した開発設定が含まれます。これらは、CDE と Solaris Motif にマップするとソースコードよりも影響を受けやすい OPEN LOOK ユーザインタフェースに固有の用語を使わずに、アプリケーションを説明している場合があります。

移行ツールの使用

アプリケーションを Solaris CDE デスクトップに移行するために必要なすべての作業を単独で実行できるようなツールは販売されていません。しかし、アプリケーションによっては、いくつかの問題を解決するツールが見つかることがあります。これらの特殊ツールにより、移行作業が簡単にできます。

利用できるツールを調べる場合は、自分のアプリケーションの移行に適しているかどうかと、自分が何をしようとしているかを確認してください。

Motif に移行するためのツール

Motif に移行するためのツールが他社からも多数販売されています。たとえば、Integrated Computer Solutions (ICS) は、2 種類のコンバータを販売しています。1 つのコンバータは XView ソースコードを GIL ファイルに変換し、もう 1 つのコンバータは GIL ファイルを Motif ソースコードに変換します。

Devguide は、ユーザの移行作業を手助けする手段として Motif 変換ユーティリティを提供します。Devguide のフロントエンドは、従来どおり OPEN LOOK ユーザインタフェースで、同じ OPEN LOOK パレットが付いていますが、Motif 変換ユーティリティを使用すると、GIL ファイルを UIL ファイルや Motif コードと C コードに変換できます。Solaris 2.4 ソフトウェア開発キットの Motif 変換ユーティリティ (guil と gmf) を使用して、GIL ファイルを UIL と Motif の C コードに変換します。UIL ファイルを Motif GUI ビルダにインポートすると、Motif ベースの GUI を生成できます。

移行ツールを使用して GUI を移行する場合には、CDE スタイルガイドに準拠するように GUI に手を加える必要が出てくることがあるので注意してください。GUI ビルダツールを使用する場合は、短時間で GUI の配置を変更できます。

Solaris CDE デスクトップに移行するためのツール

Devguide を使用してアプリケーションを作成した場合は、AppBuilder の GIL から BIL へのコンバータを使用して BIL ファイルを作成できます。BIL ファイルは、AppBuilder で使用する形式です。BIL ファイル形式は GIL ファイル形式に似ています。しかし、BIL ファイルには CDE 固有の情報が入っており、Solaris Motif GUI を作成します。GIL から BIL へのコンバータは、既存の内容に基づいて変換を推論しますが、希望どおりの結果が得られない場合があります。いい結果を得るには、コンバータが生成した BIL ファイルを取り出して AppBuilder に読み込み、必要に応じてユーザインタフェースを変更します。

AppBuilder は、OpenWindows 環境で使用される Devguide によく似た Solaris CDE 環境のツールです。この方法で CDE に移行すると、変換時の大部分の問題は解決できます。AppBuilder によってファイルが生成されるので、これらのファイルはユーザが自分で作成しなければならない C コードよりも簡単に処理できます。AppBuilder はアプリケーションのスタッブファイルを保持するので、アプリケーション固有のコードは変更されません。また、AppBuilder は Devguide と同じファイル命名規則を使用します。

Devguide 以外で OPEN LOOK アプリケーションを CDE に変換する他社のツールは、現在販売されていません。「Motif に移行するためのツール」で説明した Motif の変換ツールなどを試してください。

既存のコードの使用

この節では、Solaris CDE アプリケーションを開発するために使用または学習するコードが、Solaris CDE ソフトウェアからどのように提供されるかについて説明します。

GUI ビルダコード

AppBuilder または SunSoft Visual Workshop のような Motif GUI ビルダを使用すると、単純な Solaris CDE アプリケーションを構築できます。次に、そのアプリケーションからコードを生成し、コードの内容を調べてください。この方法により、Solaris Motif と CDE の機能をどのように使用するかを学習できます。

AppBuilder で使用できる機能が多くなるほど、生成されたコードに多数の Solaris CDE 機能を組み込むことができます。たとえば AppBuilder を使用して、オブジェクト属性を変更したり、接続を作成したり、アプリケーションフレームワークエディタを使用したりします。次に、コードを生成して検査します。このプロセスを順番に繰り返して、コードのバリエーションを生成し、そのコードを調べて学習します。

デモコード

Solaris CDE の開発環境には、アプリケーションの移植作業を大幅に軽減できるデモソースコードが含まれています。

/usr/dt/examples には、開発環境の各コンポーネントごとのデモディレクトリがあります。デモディレクトリには、そのコンポーネントの API を使用するプログラム例が入っています。デモコードを読んで、コンポーネントの動作をアプリケーションに組み込む方法を学習してください。デモコードからアプリケーションにコードをコピー＆ペーストできます。

/usr/dt/examples/template ディレクトリには、基本的な統合機能と推奨する統合機能を構成する Solaris CDE コンポーネントのほとんどを統合するデモプログラムが入っています。このテンプレートデモは、Solaris CDE デスクトップと密接に統合された単純なアプリケーションの作成方法を具体的に示しています。

ヒント

次に、CDE デスクトップ用のアプリケーションを作成するためのヒントについて説明します。

フローティングメニュー

アプリケーションが CDE デスクトップ上で正常に機能することを保証するには、一部のプルダウンメニューにもフローティングメニューに組み込んだ機能を持たせる必要があります。こうすると、アプリケーションは 2 ボタンマウスデバイスと 3 ボタンマウスデバイスのどちらでも機能するようになります。

カラーマップの動作

CDE 上では、カラーマップのインストールが OpenWindows 環境とは異なる方法で処理されます。この違いは、デフォルト以外のカラーマップを使用するサブウィンドウを指定するアプリケーションで識別できます。このサブウィンドウは、WM_COLORMAP_WINDOWS 属性で指定されます。

OpenWindows 環境では、アプリケーションはこの属性内でサブウィンドウを指定するだけですみます。ユーザが画面内でポインタを移動すると、OpenWindows のウィンドウマネージャ (olwm) は、ポインタが置かれているウィンドウ用に適切なカラーマップをインストールします。

CDE のウィンドウマネージャである dtwm は、この動作を行いません。olwm のポインタベースのカラーマップインストール機能に依存するアプリケーションを CDE 上で実行する場合は、正しい色が表示されないことがあります。この問題を回避するために、次のいくつかの対処方法があります。

また、dtwm のキーの割り当てを変更して、キーボードのキーに f.next_cmap() 関数と f.prev_cmap() 関数を設定できます。該当するキーを押すたびに、これらの関数は WM_COLORMAP_WINDOWS リスト内を前後に移動して別のカラーマップをインストールします。

まとめ: 注意事項

次に、アプリケーションを Solaris CDE デスクトップに移植する場合の注意事項を示します。