この章では、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 デスクトップに移植すると、次の利点があります。
CDE が提供する新しい機能を活用できる
多様なプラットフォームに簡単に移植できるようになる
アプリケーションが CDE スタイルガイドラインに従って動作することを保証し、より「使いやすく」することができる
Solaris CDE 環境と OpenWindows 環境が異なる領域で、他の Solaris CDE アプリケーションとの相互運用性を提供する
ウィンドウマネージャとの対話
ドラッグ&ドロップ
セッション管理
推奨する統合とオプションの統合では、コードを変更して、これらのカテゴリに含まれる機能を実装する必要があります。多数の CDE 機能を採用するほど、アプリケーションはデスクトップとさらに統合されます。
Solaris CDE 開発環境には、デスクトップ上でアプリケーションを他のアプリケーションと適正に統合できるように、次のコンポーネントとガイドラインが含まれています。
ヘルプシステム
ToolTalk メッセージシステム
セッションマネージャ
ドラッグ&ドロップ
国際化
標準フォント名
エラーメッセージのガイドライン
ユーザによるカスタマイズの問題
次の Solaris CDE コンポーネントを使用すると、デスクトップから提供されるサービスを強化して特殊なタスクを実行できます。
Solaris Motif のコントロールウィジェット
データ型
アクションの起動
ワークスペースマネージャ
端末ウィジェット
テキストエディタウィジェット
カレンダ API
デスクトップ Korn シェル
アプリケーションを Solaris CDE デスクトップに移植する計画を立てている場合、または移植の練習をする場合は、小規模な例から始めて段階的に作業を進めてください。
単純な GUI を持つ小型アプリケーションの場合は、2 段階のプロセスを使用して移植できます。
OPEN LOOK ユーザインタフェースから Motif に、GUI をオブジェクト単位で変換します (次節 「Motif GUI ビルダを使用する」を参照してください)。
変換後の GUI を CDE スタイルガイドラインに準拠するように配置します。この機会を利用して、GUI の使いやすさと顧客特有の問題点を検討します。オブジェクトごとの変換がスタイルガイドに準拠している場合でも、インタフェースを変更できます。
単純な OPEN LOOK アプリケーションと、このプロセスの具体例については、第 7 章「移植例: OPEN LOOK から Solaris Motif へ」を参照してください。
この方法は、大型アプリケーションを移植する場合にはお勧めできません。
アプリケーションビルダ (以降、AppBuilder とします) または Visual WorkShop(TM) のような Motif GUI ビルダを使用すると、アプリケーション用に新しい Motif GUI を構築できます。「変換と配置」で説明した 2 段階のプロセスを使用してポートを移植する場合は、一度試してみてから変更を加えるという柔軟な対応が必要です。特定の GUI 内で手動でコーディングする場合は、変更するのが難しく時間がかかります。AppBuilder を使用すると、オブジェクトをドラッグ&ドロップしてプロトタイプ GUI を簡単に作成できるので柔軟に対応できます。通常は、GUI ビルダを使用して新しい Motif インタフェースをレイアウトする方が、GUI を手作業で移植するよりも時間がかかりません。
実際には、使用する移植プロセスの種類やアプリケーションの大きさに関わらず、Motif GUI ビルダの使用を検討する必要があります。ビルダは GUI とアプリケーションのフレームワークコードをすべて生成するので、アプリケーションコードに専念できます。
コードをすぐに Solaris Motif に変換しないでください。まずアプリケーションのアーキテクチャを調べてから、アプリケーションを Motif と CDE に移植してください。
アプリケーションのアーキテクチャが大きいほど、アプリケーションを正しく構成し直す作業は重要になります。このような場合に「変換と配置」戦略を使用すると、移植プロセスがさらに複雑になります。
重要な機能が周辺の 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 には、同等のウィジェットはありません。 |
CDE の AppBuilder は、コロンで垂直に整列させるなど、ウィジェットを共通の位置に自動的に配置できる「グループ」というジオメトリマネージャ抽象化を提供します。この機能を実装するために、AppBuilder はすべてのコードを生成します。
CDE デスクトップは OpenWindows デスクトップとはまったく異なりますが、同じタイプのツールが多数入っています。最も明らかな違いは、CDE デスクトップは Motif デスクトップであることです。エンドユーザ環境と開発環境のアーキテクチャ構造の詳細は、『共通デスクトップ環境 プログラマ概要』を参照してください。また、次のマニュアルも参照してください。
Motif マニュアルのリストについては、「Motif 2.1 マニュアル」と 「Motif プログラミング」を参照してください。
CDE の見た目と使い心地の詳細は、『共通デスクトップ環境 スタイル・ガイド』を参照してください。アプリケーションをスタイルガイドに準拠させるには、このスタイルガイドの巻末に掲載されているチェックリストに合格しなければなりません。
提供されている CDE マニュアルのリストについては、「CDE マニュアル」を参照してください。また、デスクトップアプリケーションごとに、オンラインヘルプボリュームが用意されています。
Motif GUI ビルダを使用してアプリケーションの GUI を作成した場合は、Solaris CDE デスクトップに簡単に移行できるはずです。ほとんどの場合、ビルダを使用するとユーザインタフェースの関数とアプリケーションの内部関数をある程度分離することになります。その長所については前述のとおりです。
通常、ビルダは汎用内部記憶形式を使用するか、相互交換ファイルを生成する機能があり、各ファイルは変換プロセスの一部を自動化するために後処理できます。ビルダのベンダーに、現在どんな移行ツールを販売しているか問い合わせてください。
その他にあまり確立されていないものの移行作業を容易にするようなツールには、機能要件に関する文書や高水準の設計を生成した開発設定が含まれます。これらは、CDE と Solaris Motif にマップするとソースコードよりも影響を受けやすい OPEN LOOK ユーザインタフェースに固有の用語を使わずに、アプリケーションを説明している場合があります。
アプリケーションを Solaris CDE デスクトップに移行するために必要なすべての作業を単独で実行できるようなツールは販売されていません。しかし、アプリケーションによっては、いくつかの問題を解決するツールが見つかることがあります。これらの特殊ツールにより、移行作業が簡単にできます。
利用できるツールを調べる場合は、自分のアプリケーションの移行に適しているかどうかと、自分が何をしようとしているかを確認してください。
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 の配置を変更できます。
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 ソフトウェアからどのように提供されるかについて説明します。
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 上で実行する場合は、正しい色が表示されないことがあります。この問題を回避するために、次のいくつかの対処方法があります。
WM_COLORMAP_WINDOWS 属性をまったく使用せずに、適切なカラーマップを持つトップレベルウィンドウ (シェルウィジェットのウィンドウ) のカラーマップ属性を更新します。ウィンドウに入力フォーカスが与えられているときは、いつでもこのカラーマップがインストールされます。
WM_COLORMAP_WINDOWS 属性はウィンドウの並び順のリストであり、通常はこのリスト内の最初のウィンドウにのみカラーマップがインストールされ、正しい色で表示されます。ほとんどの場合、他のサブウィンドウは正しい色で表示されません。特定のサブウィンドウを正しい色で表示することが重要な場合は、リストの最初に配置する必要があります。
トップレベルウィンドウの ID がリストに表示されない場合は、最初に表示されるものと見なされます。サブウィンドウを正しい色で表示するには、リスト内でそのサブウィンドウの ID の後にトップレベルウィンドウの ID を配置する必要があります。
アプリケーションは、いつでも WM_COLORMAP_WINDOWS 属性を更新できます。別のサブウィンドウにそのカラーマップがインストールされるなど、アプリケーションの状態が変化する場合は、新しいサブウィンドウが最初に表示されるようにアプリケーションは属性を更新する必要があります。
また、dtwm のキーの割り当てを変更して、キーボードのキーに f.next_cmap() 関数と f.prev_cmap() 関数を設定できます。該当するキーを押すたびに、これらの関数は WM_COLORMAP_WINDOWS リスト内を前後に移動して別のカラーマップをインストールします。
次に、アプリケーションを Solaris CDE デスクトップに移植する場合の注意事項を示します。
OPEN LOOK から Motif に移行する作業は、複雑で広範囲にまたがる問題を伴います。
通常は、オブジェクトごとのスワップにはなりません。実際に移植する必要がありますか。
どんなスケジュールで作業しますか。
いつ出荷しなければなりませんか。どんなリソースを使用できますか。移植結果を次の主要リリースに結び付けることができますか。
どのような方法でアプリケーションを構築しましたか。
AppBuilder を使用しましたか。アプリケーションの生成の際に他のツールを使用しましたか。使用した場合は、CDE のサポートをベンダに問い合わせてください。
アプリケーションの GUI は内部から分離されていますか。
C++ オブジェクトを使用して GUI をカプセル化しましたか。その場合は、アプリケーションを簡単に移植できるようにします。
通常、OLIT のアプリケーションは Motif のように Xt イントリンシクスに依存しているので、OLIT アプリケーションの方が簡単に移植できます。
カスタマには何か問題がありますか。
他のシステムとの相互運用性を考慮する必要がありますか。カスタマには、移行と研修に際して問題がありますか。現在、混在型のデスクトップは受け入れられますか。