パート II 推奨する統合方法

第 2 章「フォントの統合」から第 5 章「ドラッグ & ドロップとの統合」では、次の推奨する統合作業を実行する方法を説明します。

• 標準フォントの別名を使用して、アプリケーションがデスクトップ準拠システム上で最も近いフォントを使用するようにする

• アプリケーションからエラー・メッセージを表示する

• セッション・マネージャと統合して、ログアウト時のアプリケーションの状態を保存する

• 既存の機能の直接操作アクセラレータとして、アプリケーションの中でドラッグ＆ドロップを実現する

• 第 2 章「フォントの統合」「フォントの統合」

• 第 3 章「アプリケーションからのエラーの表示」「アプリケーションからのエラーの表示」

• 第 4 章「セッション・マネージャとの統合」「セッション・マネージャとの統合」

• 第 5 章「ドラッグ & ドロップとの統合」「ドラッグ & ドロップとの統合」

第 2 章 フォントの統合

アプリケーションは、X 端末で、またはネットワークを介してリモート・ワークステーションで使用できます。このような状況では、ユーザの X ディスプレイを X Window System のサーバから使用できるフォントは、アプリケーションのデフォルトとは異なることもあり、使用できないフォントもあります。

共通デスクトップ環境 (CDE) によって定義された標準フォント名は、すべての CDE 準拠システムで使えるように保証されています。これらの名前は、実際のフォントを表すわけではありません。その代わりに、各システム・ベンダが、使用できるフォントの中で最も適したフォントにマップする別名です。アプリケーションの中でこれらのフォント名だけを使用する場合には、CDE 準拠システムで最もよく適合したフォントを使用できます。

標準アプリケーションフォント名が ISO Latin 言語環境でしか利用できないのに対して、これらの標準インタフェースフォント名はすべての言語環境で利用できることを保証されています。 詳細については、マニュアルページ、DtStdInterfaceFontNames、DtStdAppFontNames を参照してください。

• 「標準インタフェースフォント」

• 「CDE 構成ファイルでのフォントの使用」

• 「標準アプリケーションフォント」

標準インタフェースフォント

デフォルトのフォント名

標準的なインタフェースフォント名のセットは、表 2-2で説明する XLFD フィールド名の値によって定義されます。

標準インタフェースフォントのポイント数

3 つのスタイルそれぞれの 7 つの名前付きポイント数が ADD_STYLE_NAME フィールドに付加されます。 XLFD フォントのパターンは、数値の大きさではなく、名前付きサイズに一致します。これらの名前付きサイズが使われるのは、インタフェースフォントについては、その正確なサイズよりも名目上のフォントサイズが優先されるためです。また、個別に調整されたインタフェースフォントに起因する実装の差異によって、異なるシステム間に共通するポイント数を設定できないためです。

7 つのサイズ名は次の通りです。

名前付けされたサイズを用いるのは、CDE が実行されるさまざまなモニタサイズと解像度に対応するだけの、十分なフォント数を提供するためです。また、ボタンラベル、ウィンドウ名などのさまざまなユーザー設定に GUI を適合させるためです。ただし、最も小さい xxl と最も大きい xxs は、一般的なディスプレイや X 端末を利用して CDE デスクトップで表示するのに最適なものとして用意されているもので、精度の低い印刷や見出しサイズのディスプレイには適しません。

標準インタフェースフォント名のパターン

XLFD パターンは、次のとおりです。

-dt-interface*-*

これらの値によって、XCDE 標準インタフェースフォント名のフルセットに論理的に適合します（特定のＸサーバーの動作が暗黙に定義されるわけではないことに注意してください）。

例えば、西欧語のロケールでは、21の CDE 標準インタフェースフォント名が表示されます。

-dt-interface system-medium-r-normal-*-*-*-*-*-*-*-iso8859-1
-dt-interface user-medium-r-normal-*-*-*-*-*-m-*-iso8859-1
-dt-interface user-bold-r-normal-*-*-*-*-*-m-*-iso8859-1

7 つのシステムフォントサイズすべてについての、app-defaults ファイル内のパターンのフルセットは次のとおりです。

-dt-interface system-medium-r-normal-xxs*-*-*-*-*-*-*-iso8859-1
-dt-interface system-medium-r-normal-xs*-*-*-*-*-*-*-iso8859-1
-dt-interface system-medium-r-normal-s*-*-*-*-*-*-*-iso8859-1
-dt-interface system-medium-r-normal-m*-*-*-*-*-*-*-iso8859-1
-dt-interface system-medium-r-normal-l*-*-*-*-*-*-*-iso8859-1
-dt-interface system-medium-r-normal-xl*-*-*-*-*-*-*-iso8859-1
-dt-interface system-medium-r-normal-xxl*-*-*-*-*-*-*-iso8859-1

これらのパターンはリソースファイルで使用することができ、すべての CDE 対応のシステム上の iso Latin-1 ロケール用の CDE 標準インタフェース名と一致します。詳細については、DtStdInterfaceFontNames(5) マニュアルページを参照してください。

CDE 構成ファイルでのフォントの使用

CDE は、すべてのプラットフォーム上の CDE で動作するアプリケーションで使用できる一般的な標準アプリケーション・フォント名のセットを、いくつかのサイズにおいて指定します。各 CDE ベンダは、標準フォント名のセットを使用可能なフォントにマップします。既存のフォントへのフォント名のマッピングは、ベンダによって異なります。

app-defaults ファイルの中で標準アプリケーション・フォント名を使用すると、すべての CDE プラットフォームで単一の app-defaults ファイルを使用できます。標準フォント名を使用しない場合には、各 CDE プラットフォーム上の各アプリケーションごとに別の app-defaults ファイルをそれぞれ提供しなければなりません。

すべての CDE システムは、13 の標準アプリケーション・フォント名のセットを、少なくとも 6 サイズで提供します。これは、12 の一般的なデザインと変形スタイル (serif および sans serif)、および記号フォントを表します。これらの標準名に加えて、特定の CDE プラットフォームに対応して標準名がマップされるフォント名が提供されます。また、追加の 4 つの標準フォント名 (固定幅フォント内に serif と sans serif の両方のデザインを可能にします) が CDE プラットフォーム・ベンダによって提供されることもあります。

これら 13 のフォント名は、ISO 8859-1 の文字セットを使用するロケールのために、CDE プラットフォームの中に用意されています。他のロケールでの標準フォント名の使用方法については、『Solaris 共通デスクトップ環境 プログラマーズ・ガイド(国際化対応編)』を参照してください。

標準アプリケーションフォント

デフォルトのフォント名

フォント名のセットは、表 2-2 に示されている XLFD フィールド名の値によって定義されます。

標準名は、X Windows XLFD フォント命名スキーマに従って使用できます。プラットフォーム依存フィールドに対して適切なワイルドカードで正しく指定すれば、CDE フォント名は、有効な、対応するプラットフォーム依存フォントを確実に開きます。ただし、Xlib の XListFont() 関数の呼び出しから返される XLFD 名は、すべての CDE プラットフォーム上で同じであるとは限りません。

このような値を使うと、次の XLFD パターンは、特定のプラットフォーム上の CDE 標準 アプリケーション・フォント名のセットのすべてと一致します。

-dt-application-*

次のパターンは、CDE のボールドのプロポーショナルスペース・フォント (serif と sans serif の両方) に一致します。

-dt-application-bold-*-*-*-*-*-*-*-p-*-*-*-

また、次のパターンは、固定幅フォントに一致します (serif または sans serif、あるいは両方)。

-dt-application-*-*-*-*-*-*-*-*-m-*-*-*-

CDE 標準アプリケーション・フォント名のセットのすべては、次のように表すことができます。

-dt-application-bold-i-normal-serif-*-*-*-*-p-*-iso8859-1
-dt-application-bold-r-normal-serif-*-*-*-*-p-*-iso8859-1
-dt-application-medium-i-normal-serif-*-*-*-*-p-*-iso8859-1
-dt-application-medium-r-normal-serif-*-*-*-*-p-*-iso8859-1
-dt-application-bold-i-normal-sans-*-*-*-*-p-*-iso8859-1
-dt-application-bold-r-normal-sans-*-*-*-*-p-*-iso8859-1
-dt-application-medium-i-normal-sans-*-*-*-*-p-*-iso8859-1
-dt-application-medium-r-normal-sans-*-*-*-*-p-*-iso8859-1
-dt-application-bold-i-normal-*-*-*-*-*-m-*-iso8859-1
-dt-application-bold-r-normal-*-*-*-*-*-m-*-iso8859-1
-dt-application-medium-i-normal-*-*-*-*-*-m-*-iso8859-1
-dt-application-medium-r-normal-*-*-*-*-*-m-*-iso8859-1
-dt-application-medium-r-normal-*-*-*-*-*-p-*-dtsymbol-1

ポイント・サイズ

それぞれの標準アプリケーション・フォント名で使用できるポイント・サイズの完全なセットは、ベンダの CDE プラットフォームで出荷されるフォントのセットによって決まります (ビットマップ・フォントのみか、ビットマップ・フォントとスケーラブル・アウトライン・フォントの両方)。すべての CDE プラットフォーム上で使用できる必要最小限のサイズのセットは、X11R5 のデフォルトのマッピングを構成するビットマップ・フォントの標準サイズ (8、10、12、14、18、または 24) に対応します。

たとえば、単純な固定幅フォントの 6 サイズの全セットを次のパターンによって表すことができます。

-dt-application-medium-r-normal-*-80-*-*-*-m-*-iso8859-1
-dt-application-medium-r-normal-*-100-*-*-*-m-*-iso8859-1
-dt-application-medium-r-normal-*-120-*-*-*-m-*-iso8859-1
-dt-application-medium-r-normal-*-140-*-*-*-m-*-iso8859-1
-dt-application-medium-r-normal-*-180-*-*-*-m-*-iso8859-1
-dt-application-medium-r-normal-*-240-*-*-*-m-*-iso8859-1

これらのパターンは、CDE プラットフォーム上の対応する標準フォント名に一致しますが、POINTSIZE 以外の数値フィールドはプラットフォームによって異なる場合があります。また、ベンダが標準名のセットを実装する方法によって、一致するフォントは serif か sans serif のどちらかになります。

app-defaults ファイル内の標準アプリケーション・フォント名

一つの app-defaults ファイルを作成してアプリケーションのフォント・リソースを指定し、それをすべての CDE プラットフォームで使用できます。定義される標準名の部分は、どのベンダのプラットフォームでも同じなので、app-defaults ファイルの中のリソース指定でこれらの値を指定できます。ただし、その他のフィールド (PIXEL_SIZE、RESOLUTION_X、RESOLUTION_Y、および AVERAGE_WIDTH) はプラットフォームによって異なることがあるので、ワイルドカードを使用しなければなりません。たとえば、appOne という名前のアプリケーションが必要とするデフォルトのリソースを指定するには、次のようにします。

appOne*headFont:
-dt-application-bold-r-normal-sans-*-140-*-*-p-*-iso8859-1 

appOne*linkFont:
-dt-application-bold-i-normal-sans-*-100-*-*-p-*-iso8859-1

もう一つの例として、あるベンダのプラットフォーム上で動作する appTwo は、見出しとハイパーテキスト・リンクのために 2 つのフォント・リソースを定義すると仮定します。appTwo は、14 ポイントのボールドの serif フォント (Lucidabright bold) と 12 ポイントのボールドかつイタリックの sans serif フォント (Lucida bold-italic) を使用します。その場合、app-defaultsファイル内のフォント定義を、

apptwo *headingFont:
-b&h-lucidabright-bold-r-normal--20-140-100-100-p-127-iso8859-1 

apptwo *linkFont:   
-b&h-lucida-bold-i-normal-sans-17-120-100-100-p-96-iso8859-1

から

apptwo *headingFont: 
-dt-application-bold-r-normal-serif-*-140-*-*-p-*-iso8859-1

apptwo *linkFont:   
-dt-application-bold-i-normal-sans-*-120-*-*-p-*-iso8859-1

に変更します。他の CDE プラットフォーム上のフォント名がわからなくても、CDE 標準アプリケーション・フォント名で指定されたプラットフォームに独立したパターンは、各プラットフォーム上の適切なフォントを示します。

リソース定義の中で、*ワイルドカードを使用して示した例のように作成します。ポイント・サイズ以外の数値フィールドにワイルドカードを適用することによって、フォントの正確なピクセル・サイズまたは平均の幅が多少違っても、リソースがすべてのプラットフォーム上の CDE フォントに必ず一致するようにできます。

詳細は、DtStdAppFontNames(5) マニュアルページを参照してください。

第 3 章 アプリケーションからのエラーの表示

アプリケーションを実行しているユーザは、メッセージ・フッタ、エラー・ダイアログ、または警告ダイアログにメッセージが表示され、適宜、詳しい説明がオンラインヘルプにあることを期待します。共通デスクトップ環境のアプリケーションは、エラー・メッセージと警告を表示するための共通モデルに従います。

• 「エラー・メッセージの表示方法」

• 「エラー・ダイアログに表示する情報」

• 「メッセージ・ダイアログとオンライン・ヘルプのリンク」

• 「回復処理ルーチン」

エラー・メッセージの表示方法

メッセージ・テキストの処理方法のために、ダイアログ、フッタ、または別のユーザ・インタフェースのどこかに表示しないと、ユーザはアプリケーションからのメッセージを見ることができません。

共通デスクトップ環境 (CDE) では、そのようなメッセージは、通常のユーザが定期的に調べることのないログ・ファイルに出力されます。警告、メッセージ、およびエラー条件を表示する場所を決めるときには、次の規則に従ってください。

• 情報を示すメッセージの場合は、アプリケーションのメッセージ・フッタにテキストを表示します。たとえば、「MyDoc ファイルがコピーされました」のようになります。

• エラーまたは重大な警告についてのメッセージの場合は(ユーザにとって重要な操作が失敗した場合のトラブルなど) 、エラー・ダイアログまたは警告ダイアログに表示します。

エラー・ダイアログに表示する情報

優れたエラー・ダイアログまたは警告ダイアログでは、次の情報をユーザに提供します。

• 何が起きたか (ユーザの視点から)

• 原因 (ユーザが現在の作業と環境に関連づけて理解できるような簡単な表現で)

• 問題の解決方法

4、5 行のエラー・ダイアログで説明できない場合には、ダイアログにヘルプ・ボタンを追加して、ヘルプ・ボタンをアプリケーションのヘルプ・ボリューム内のトピックにリンクすることを検討してください。

メッセージの作成の詳細は、『Solaris 共通デスクトップ環境 プログラマーズ・ガイド(国際化対応編)』を参照してください。

メッセージ・ダイアログとオンライン・ヘルプのリンク

追加の背景情報が必要な場合や、4、5 行のダイアログではエラーを十分に説明できない場合には、オンライン・ヘルプにリンクするボタンを追加できます。

ダイアログのオンライン・ヘルプの追加は単純な作業です。特定のダイアログをオンライン・ヘルプの候補として決めたら、次の作業を実行します。

1. エラー・ヘルプに対して固有な ID を選択します。

   この ID が、オンライン・ヘルプ・テキストへのリンクとなります。ID は、64 文字以下でなければなりません。たとえば、DiskSpaceError のようになります。

2. ダイアログを作成して、ヘルプ・コールバックを追加します。

   エラー・メッセージに対しては XmCreateErrorDialog()簡易関数を、警告に対しては XmCreateWarningDialog()簡易関数を使用して、次のようにヘルプ・コールバックを追加します。

   XtAddCallback(dialog, XmNhelpCallback,	helpfn, "ID");

   この例では、helpfn はヘルプ・ダイアログを管理するために作成したヘルプ関数、文字列「ID」は、エラー・メッセージに対して選んだ ID です (たとえば、 DiskSpaceError)。ヘルプ関数では、XmNlocationId リソースを ID の値に設定します。/usr/dt/examples/dthelp ディレクトリに、このようなヘルプ関数の設定例があります。

   ヘルプ・ダイアログ・ウィジェットの作成と管理の詳細は、『Solaris 共通デスクトップ環境 プログラマーズ・ガイド(ヘルプ・システム編)』を参照してください。

3. エラー・メッセージに対応するヘルプ・セクションを書きます。

   ヘルプ・ボリュームの「メッセージ」の章に、メッセージの説明を書きます。ヘルプのソース・ファイルでは、メッセージごとにセクションを設けなければならず、セクションの始めの ID= 属性は、コードの中でエラーに対して選んだ ID と一致しなければなりません。

   たとえば、s1 セクション見出しでは、ID は DiskSpaceError です。

   次の見出しは、ユーザのシステムに十分なディスク領域がないときに、「ファイルを保存できません」というエラー・メッセージを表示します。

       <s1 ID=DiskSpaceError> ファイルを保存できません <¥s1>

   規則によって、セクション見出しのテキストはエラー・ダイアログのテキストと 1 対 1 で対応しなければならないので注意してください。

4. ヘルプ・ファイルを再作成します。

   エラー・メッセージに対する新しいヘルプ・セクションは、ヘルプ・ファイルを再作成して (dthelptag プログラムを使用して)、アプリケーションを再コンパイルするとすぐにアクティブになります。

オンライン・ヘルプの記述と作成方法の詳細は、『Solaris 共通デスクトップ環境 プログラマーズ・ガイド(ヘルプ・システム編)』を参照してください。

回復処理ルーチン

エラー条件のための回復処理ルーチンがある場合には、ダイアログに [再実行] ボタンを追加することを検討してください。たとえば、システムのディスク空間が不足しているためにファイルをコピーできなかった場合、ダイアログに [再コピー] オプションがあれば、ユーザは、ディスク空間やアクセス権の問題を訂正してから、そのオプションを選択できます。

第 4 章 セッション・マネージャとの統合

セッション・マネージャは、ユーザが (現在のセッションから) ログアウトするときや、ユーザが (ホーム・セッションとして) 環境を保存するときに、デスクトップ環境と実行中のアプリケーションに関する情報を保存します。アプリケーションが現在のセッションまたはホーム・セッションの一部として保存され、次のセッションの一部として再起動されるためには、X クライアント間通信規約マニュアル (ICCCM) 1.1 のセッション管理プロトコルを理解できる必要があります。この章では、セッション・マネージャがセッションを保存して復元する方法を概説し、アプリケーションがセッション管理に関与するために必要な手順を詳しく述べます。

• 「セッション・マネージャがセッションおよびアプリケーションを保存する方法」

• 「セッション管理のためのアプリケーションのプログラム方法」

• 「セッション・マネージャがセッションを復元する方法」

セッション・マネージャがセッションおよびアプリケーションを保存する方法

セッションを終了するときや、ホーム・セッションを保存するとき、セッション・マネージャは次の作業を実行します。

1. 選択されたリソース設定と X サーバ設定を保存する。

2. 各アプリケーションが状態を保存できるようにして、保存の完了を待つ。

3. アプリケーションの再起動に必要なコマンド行を獲得する。

セッション管理のためのアプリケーションのプログラム方法

プログラム環境の設定

この節では、統合プロセスの一部としてアプリケーションを保存するために必要なプログラミングの手順を説明します。

プログラム環境を設定するには、次の手順に従います。

1. 次のヘッダ・ファイルを組み込みます。

   • Xm/Xm.h

   • Xm/Protocols.h

   • Dt/Session.h

2. libXmと libDtSvcをリンクします。

3. ツールキットを初期化して、トップレベル・ウィジェットを作成します。

WM_SAVE_YOURSELF アトムの設定

次の例に示すように、Motif の XmAddWMProtocol() 関数を使用して、アプリケーションのトップレベル・ウィンドウの WM_PROTOCOLS 属性の WM_SAVE_YOURSELF アトムを設定します。

Atom XaWmSaveYourself; 
Display *dsp;
dsp = XtDisplay(toplevel);
XaWmSaveYourself = XmInternAtom(dsp,
"WM_SAVE_YOURSELF", False); 

XmAddWMProtocols(toplevel, &XaWmSaveYourself, 1);

複数のウィンドウに対して WM_SAVE_YOURSELF アトムを設定しないでください。

WM_SAVE_YOURSELF メッセージを受け取るための準備

Motif の XmAddWMProtocolCallback() 関数を使用して、アプリケーションが WM_SAVE_YOURSELF クライアント・メッセージを受け取ったときに呼び出されるコールバック・プロシージャを設定します。

XmAddWMProtocolCallback(toplevel,
XaWmSaveYourself, SaveYourselfProc,
toplevel);

WM_SAVE_YOURSELF メッセージの処理

セッション・マネージャがこのアプリケーションのトップレベル・ウィンドウに WM_SAVE_YOURSELF クライアント・メッセージを送ると、SaveYourselfProc() コールバック・プロシージャが呼び出されます。このコールバックを使用して、アプリケーションの状態を保存します。アプリケーションはプログラマが選んだ任意の方法で状態を保存できますが、保存中はユーザと対話できません。

セッション・マネージャは、アプリケーションの状態を保存するための絶対パス名とベース・ファイル名を返す手段として、DtSessionSavePath() 関数を提供します。

WM_COMMAND 属性の設定

アプリケーションが WM_SAVE_YOURSELF メッセージの処理 (状態を保存するか、メッセージを無視する) を終了した後、アプリケーションはトップレベル・ウィンドウの WM_COMMAND 属性を設定して、保存操作が完了したことをセッション・マネージャに知らせなければなりません。

アプリケーションのトップレベル・ウィンドウの WM_COMMAND 属性を設定するには、Xlib の XSetCommand() 関数を使用します。この属性を設定することによって、アプリケーションが WM_SAVE_YOURSELF メッセージの処理を終了したことをセッション・マネージャに知らせ、アプリケーションを再起動するために必要なコマンド行をセッション・マネージャに与えます。

XSetCommand() は、コマンド引き数の配列を受け入れます。アプリケーションが保存プロセスの一部として DtSessionSavePath() 関数を使用する場合には、XSetCommand() には追加のコマンド引き数 -session basename が必要です。basename は、DtSessionSavePath() によって返されるベース・ファイル名です。

セッション・マネージャがセッションを復元する方法

セッション・マネージャは、次のようにしてセッションを復元します。

1. リソース・データベースとサーバ設定を復元する。

2. 保存されたコマンドを使用して、アプリケーションを再起動する。

アプリケーションが、保存された状態のパスを見つけるために DtSessionSavePath() を使用した場合には、アプリケーションは、ベース・ファイル名を-session 引き数から DtSessionRestorePath() 関数に渡して、保存状態ファイルの絶対パス名を見つけることができます。

第 5 章 ドラッグ & ドロップとの統合

この章では、ドラッグ & ドロップ・ユーザ・モデルと共通デスクトップ環境 (CDE) のドラッグ & ドロップ簡易アプリケーション・プログラム・インタフェース (API) を説明し、ドラッグ & ドロップの使い方を説明します。

• 「概要」

• 「ドラッグ & ドロップ・ユーザ・モデル」

• 「ドラッグ & ドロップ簡易 API」

• 「ドラッグ & ドロップ処理」

• 「統合アクション・プラン」

• 「API の概要」

• 「ドラッグ・ソースの使い方」

• 「ドロップ領域の使い方」

概要

共通デスクトップ環境 (CDE) には、あらゆるデスクトップを通じて操作に一貫性のある便利なドラッグ & ドロップを提供するために、Motif に基づくドラッグ & ドロップのためのアプリケーション・プログラム・インタフェース (API) があります。CDE のドラッグ & ドロップ API は、開発者によるドラッグ & ドロップの実現をより簡単にします。ドラッグ & ドロップを使うと、ユーザは、画面上のオブジェクトをグラブし、ディスプレイ上をドラッグし、他のオブジェクトの上にドロップするという直接操作によって、データを転送できます。

テキスト、ファイル、およびバッファは、CDE のドラッグ & ドロップ API で使用されるデータの 3 つのカテゴリです。この文脈のテキストは、入力フィールドのテキストのように、ユーザの目に見えるテキストとして定義されます。ファイルは、ファイル・システム内にあるデータのコンテナです。各ファイルは、その内容を記述する形式を持ちます。バッファは、メモリに含まれるデータです。特徴として、各バッファはその内容を記述する形式を持ちます。

ライブラリとヘッダ・ファイル

ドラッグ & ドロップを使用するには、DtSvc ライブラリをリンクする必要があります。ヘッダ・ファイルは Dt/Dnd.h です。

デモ・プログラム

ドラッグ & ドロップの例が入っているデモ・プログラムは、/usr/dt/examples/dtdnd にあります。

ドラッグ & ドロップの使い方

ドラッグ & ドロップと統合するには

ドラッグ & ドロップとアプリケーションを統合するには、次の手順に従います。

1. Dt/Dnd.h を組み込みます。

2. libDtSvc をリンクします。

3. 受信側は次の作業を実行します。

   1. DtDndDropRegister を使用して、ドロップ領域を登録します。

   2. オプション。ドロップ・アニメーションのコールバックを書くこともできます。

   3. 転送コールバックを書きます。

4. 送信側は次の作業を実行します。

   1. ユーザ・アクションを認識し (変換テーブルの変更が必要な場合があります)、DtDndDragStart を呼び出します。

   2. 変換コールバックを書きます。

   3. ドラッグ終了コールバックを書きます。

ドラッグ & ドロップ・ユーザ・モデル

この節では、デスクトップの他の部分に矛盾せずに、ユーザの期待に反しないアプリケーションが設計できるように、ドラッグ & ドロップの基本となるユーザ・モデルを説明します。

ドラッグ & ドロップの詳細と、ドラッグ & ドロップ要素の外観に関するガイドラインについては、『共通デスクトップ環境 スタイル・ガイド』を参照してください。

ドラッグ & ドロップをデスクトップ上のすべてのアプリケーションで使用できれば、システムはユーザにとってより予測可能なものとなり、したがって、より使いやすく覚えやすくなります。ユーザは、すでに知っている技術を使うことによって、自分が学んだことをより多くのアプリケーションに応用できます。また、多くのユーザはメニューを使うよりもドラッグ & ドロップを好みます。

この章では、ユーザが何かをドロップできる場所としてドロップ領域という用語を使用します。ドロップ領域は、通常、コントロールまたはグラフィック・アイコンによって表示されます。たとえば、ごみ箱アイコンや入力フィールドのグラフィックです。ドロップ領域を表す矩形の領域には、ドロップ・ターゲットという用語を使用します。

ドラッグ & ドロップ機能

ドラッグ & ドロップ機能があれば、ユーザはアイコンとして表されたオブジェクトを選択し、操作できます。

ドラッグ & ドロップは、アプリケーション内でサポートされている他のユーザ・インタフェース・コントロールを通して使用できる機能のアクセラレータです。ただし、すべてのユーザがドラッグ & ドロップを利用できるわけではありません。基本的な操作は、ドラッグ & ドロップ以外にもサポート方法を用意してください。アプリケーションがドラッグ & ドロップを通してサポートする基本的な機能は、メニュー、ボタン、またはダイアログ・ボックスによってもサポートされなければなりません。

ドラッグ・アイコン

ユーザがドラッグ & ドロップを使用してアイコンを選択し、操作するときには、ドラッグされる項目を表すグラフィック・アイコンは、選択からドラッグ & ドロップの終了まで一貫していることをユーザは期待します。ユーザがファイル・マネージャのメッセージ・アイコンを選択してドラッグを開始した場合には、ドラッグ・アイコンの元の部分は、そのメッセージ・アイコンによって表されます。このような一貫性を与えることで、ドラッグ & ドロップはユーザにとって予測可能なものになります。転送先アプリケーションがアイコンを使用する場合、ほとんどのアイコンは、選択されてドラッグ & ドロップされたアイコンと同じでなければなりません。ただし、この動作は、すべてのアプリケーションで常に適切であるとは限りません。テキストのドラッグは例外です。選択されたテキストをドラッグする代わりに、テキスト・ドラッグ・アイコンが使用されます。

転送元と転送先の両方のアプリケーションが、ドラッグ・アイコンの外観を指定します。アプリケーションが一貫した適切なドラッグ・アイコンを持つようにするのは、開発者の責任です。ドラッグ & ドロップ・ライブラリはデフォルトのアイコンを提供しますが、各アプリケーションのために開発者が独自のアイコンを指定するとよいでしょう。アイコンとそのアイコンによって表されるデータ型を関連付けるために、データ型データベースを使用しなければならない場合があります。詳細は、第 9 章「データ型データベースのアクセス」を参照してください。

ユーザがアイコンを選択せずにドラッグを開始する場合は、関連するドラッグ・アイコンを提供しなければなりません。たとえば、アポイント・エディタでは、ユーザはスクロール・リストからアポイントを選択できますが、アイコンが表示される場合と表示されない場合があります。ソース・インジケータとしてアポイント・アイコンを使用しなければなりません。転送先アプリケーション (たとえば、ファイル・マネージャ) は、同じアポイント・アイコンを表示しなければなりません。

ドラッグ・アイコンの各部

ドラッグ・アイコンがドロップ領域の上に来ると、ドラッグオーバ・フィードバックを提供するために外観が変化します。

ドラッグ・アイコンには次の 3 つの部分があり、その組み合わせによってドラッグオーバ・フィードバックを提供します。

• 状態インジケータ

• 操作インジケータ

• ソース・インジケータ

状態インジケータは、有効または無効ドロップ領域インジケータと組み合わされて、位置付けのために使用されるポインタです。有効状態インジケータは、矢印ポインタです。このポインタにはホット・スポットがあるので、ユーザは予測可能な方法で位置付けることができます。無効状態インジケータは、円と斜線の組み合わせであり、ユーザが無効なドロップ領域の上にカーソルを置いたときに表示されます。

操作インジケータは、ドラッグ時に行われる操作 (移動、コピー、またはリンク) に関するフィードバックをユーザに与えます。ほとんどのドラッグは移動なので、より頻度が少ないコピーまたはリンク操作を実行するときには、追加のフィードバックが与えられます。

操作フィードバックは、状態フィードバックとソース・フィードバックの手前に表示されます。この動作は、Motif のドラッグ & ドロップ動作と一致しています。

ユーザは、表 5-1 に示されている特定のキーを押しながらドラッグすることによって、ドラッグ操作 (移動、コピー、またはリンク) を選択できます。

ファイル・マネージャの読み取り専用ウィンドウの場合のように、転送元アプリケーションがコピーを強制することもあります。ユーザが操作を選択したときに、ドロップ領域がその操作と一致しなければドロップできません。一致しない場合には、ドロップ領域は無効です。つまり、ユーザが [Control] キーを押してコピーを選択して、ドラッグ・アイコンをごみ箱アイコンへドラッグした場合には、ごみ箱へのコピーは許可されません。このため、ドラッグ・アイコンはごみ箱アイコンを無効なドロップ領域として表示しなければならず、ドロップは失敗します。

ソース・インジケータは、選択 (すなわち、ドラッグされている項目) を表します。ソース・インジケータは、選択が 1 つの項目または複数の項目を表すか、あるいは選択が表す項目の種類によって変化します。

ウィンドウ内部からのドラッグ

アプリケーションは、ダイアログ・ボックスまたはウィンドウ内部からのドラッグを可能にする必要がある場合があります。カレンダのアポイントエディタには、アポイントのスクロール・リストとアポイントを編集するための入力領域があります。ユーザは、スクロール・リストからアポイントをドラッグできますが、アポイント入力領域からもドラッグできなければなりません。ユーザが入力領域からドラッグできるのは、アポイントがまだカレンダに挿入されていないときです (たとえば、申し込まれたミーティングの時間を入力したが、カレンダに挿入していないときなどです)。

ドラッグできる項目には、アイコン・グラフィックを関連付ける必要があります。ダイアログ・ボックスのグラフィック・アイコンは、ドラッグされる情報に隣接する適切な領域に置きます。ダイアログ・ボックスまたはウィンドウの右上隅が、望ましいデフォルトの位置です。このアイコンは何かをドラッグできることをユーザに知らせます。また、使用するグラフィックは、ドラッグ・アイコンに使用するグラフィックと同じにして、一貫性を持たせます。アイコンは 32 * 32 ピクセルでなければならず、ファイル・マネージャが使用するアイコンと同様のラベルがなければなりません。詳細は、『共通デスクトップ環境 スタイル・ガイド』の第 3 章「ドラッグ & ドロップ」を参照してください。

ドラッグが可能なのは、選択できるコンポーネントまたは項目を持つヒューマン・インタフェース要素からだけです。ボタンまたはメニューのラベルなど、静的なラベルからはドラッグできません。

視覚的なフィードバック

この節では、ドロップ領域フィードバックとドラッグ & ドロップの遷移効果を説明します。

ドロップ領域フィードバック

デフォルトのドロップ領域フィードバックをドラッグアンダといい、領域を囲む実線、ドロップ領域を囲む斜角の付いた浮き出した表面かくぼんだ表面、またはドロップ領域の上に描かれたピックスマップで表されます。

遷移効果

遷移効果は、ドロップが成功したか失敗したかをユーザに知らせます。メルトとスナップバックという 2 つの遷移効果があります。

メルトは、ユーザがドラッグ・アイコンを有効なドロップ領域にドロップしたときに発生します。ユーザがドラッグ・アイコンを有効なドロップ領域にドロップすると、ドラッグ・アイコンは、ドロップ領域に溶けてなくなります。ドラッグ・アイコンは、転送先アプリケーションにふさわしいアイコンに置き換えられます。フロントパネルのプリンタは、メルト効果以外には何も示しません。開いているファイル・マネージャ・ウィンドウは、適切なアイコンを表示することがあります。

アイコンがドロップされても、メルト効果が直ちに起こらないこともあります。転送が完了するまで、アイコンが位置していた場所に表示されています。転送中は、転送先のカーソルをビジー状態に設定してください。転送が完了するまで、ユーザはアイコンを動かしたり、選択したりできません。ビジー・カーソルによって、転送中であることをユーザに知らせます。

スナップバックは、ドロップが失敗したときに発生します。ドロップの失敗には、2 通りあります。ユーザが無効なドロップ領域にドラッグ・アイコンをドロップした場合には、ドラッグ・アイコンは転送元アプリケーションへ戻ります (スナップバックします)。ドロップが発生したら、転送元と転送先のアプリケーションはデータを転送しなければなりません。データ転送が失敗した場合には、ドラッグ・アイコンはスナップバックし、転送先アプリケーションは失敗したことをユーザに通知し、ドロップが失敗した理由を示さなければなりません。

ドラッグ & ドロップの転送元 (ソース)

ドラッグ & ドロップの転送元の動作が理解できるように、表 5-2 に、選択されたテキスト、ファイル、およびバッファのドラッグ・ソースにできる主なデスクトップ・コンポーネントを示します。

* Motif テキスト・フィールドの転送元が選択されたアプリケーションは、テキストをドラッグします。

ドラッグ & ドロップの転送先

次のデスクトップ・コンポーネントは、ドロップ先になります。

• エディタ

• ファイル・マネージャ

• フロントパネル

各コンポーネントは、選択されたテキスト、ファイル、およびバッファのドロップを受け入れます。テキスト・ドロップの転送先のほとんどは、Motif ライブラリによって自動的に提供されます。ファイルまたはバッファ・データのドロップ先がドロップを受け入れるためには、プログラムを追加しなければなりません。

ユーザがファイルからデータをドロップして、そのファイルが何らかの方法で変更されたときには、ファイルの元の保持者へ変更を書き戻すことができます。この動作をセーブバックといいます。ただし、データがバッファからドロップされたときには、データは元のファイルに関する情報を持ちません。つまり、データの元の保持者がないので、バッファからのデータに加えられた変更を書き戻すことはできません。この動作をセーブバックなしといいます。

たとえば、メール・プログラムは、ドラッグ & ドロップを使用して、メール・アタッチメントをエディタにエクスポートできます。アタッチメントがバッファとしてエクスポートされた (セーブバックがない) 場合、エディタでメール・プログラム内の元のアタッチメントを変更する手段はありません。したがって、エディタは、アタッチメントの変更済みの版を新しいファイルに保存するしかありません。

メール・アタッチメントは、すでに別のファイルではない (メール・フォルダ・ファイルに埋め込まれている) ので、バッファとしてエクスポートされるだけで、他のエディタによって保存できません。

アタッチメントがファイルとしてエクスポートされた (セーブバックがある) 場合には、エディタは変更済みのものを同じファイルに保存します。

表 5-3 は、テキスト・エディタ、アイコン・エディタ、カレンダ、メール・プログラムなどのエディタ型コンポーネントへ、選択されたテキスト、ファイル、およびバッファをドロップする場合を示します。

表 5-4 は、ファイル・マネージャ内のファイルとフォルダ・アイコンへ、選択されたテキスト、ファイル、およびバッファをドロップする場合を示します。

表 5-5 は、フロントパネルのアクション・アイコンへ、選択されたテキスト、ファイル、およびバッファをドロップする場合を示します。

ユーザに対するドラッグ & ドロップの表示方法とガイドラインの詳細は、『共通デスクトップ環境 スタイル・ガイド』を参照してください。

ドラッグ & ドロップ簡易 API

CDE は、デスクトップ内の一貫性と相互運用を促進し、開発者によるドラッグ & ドロップの実現を容易にするために、ドラッグ & ドロップ簡易 API を提供します。

ドラッグ & ドロップのための既存の Motif の API は、トランザクション中の転送元と転送先アプリケーションの通信を達成するための合理的な機能を提供します。データ転送のためのフレームワークを提供しますが、実際のデータ転送の詳細はアプリケーションに依存します。デスクトップ内のアプリケーション間の真の一貫性と相互運用のためには、すべてのアプリケーションが同じデータ転送プロトコルを使用しなければなりません。CDE のドラッグ & ドロップ簡易 API は、共通のデータ転送ルーチンを提供します。

開発者が簡単に使用できる

ドラッグ & ドロップのための既存の Motif の API は非常に柔軟性がありますが、その分、未熟な開発者にとっては使いにくい点もあります。CDE のドラッグ & ドロップ簡易 API は、次に説明するいくつかの簡易関数とサービスを提供することによって、より簡単で使いやすい API になっています。

• ドラッグ・アイコンの構成と外観を管理します。Motif のドラッグ・アイコンを構成するデフォルトのソース、状態、および操作アイコンのグラフィックが用意されています。これらのアイコンの組み合わせによって、ドラッグされているデータの型をチェックします。

• ドロップのアニメーションを可能にします。ドロップが完了したときに呼び出されるアニメーション・プロシージャを定義できます。

• テキスト、ファイル、およびバッファ転送のために、標準の X Window System の選択ターゲットを使用してデータ転送を提供します。このデータ転送は、標準のターゲットを直接使用する他のアプリケーションとの相互運用を可能にします。

• 二重登録を提供します。テキスト・ウィジェットをテキスト以外のデータのためのドロップ領域として登録できます。その場合でも、テキストのドロップを受け入れる機能は変わりません。

ポリシーの確立

ドラッグ & ドロップ API は、次の 3 つの分野のポリシーを確立します。

• 共通ターゲット。使用可能な場合には、クライアント間通信規約マニュアル (ICCCM) によって定義された既存の選択ターゲットが使用されます。

• データ転送プロトコル。API は、データ転送の詳細を隠し、データを単純なデータ構造体の形でアプリケーションに提示します。

• デフォルトのドラッグ・アイコン。デフォルトのドラッグ・アイコンは、それらを受け入れることができるアプリケーションのために用意されています。

共通の機能性の提供

ドラッグ & ドロップ API は、次の分野での共通の機能性を提供します。

• テキスト、ファイル名、およびバッファとしてのデータ転送をサポートします。

• データ転送フレームワークによって、新しい組み込みプロトコルの追加をサポートします。

既存の Motif API の応用

ドラッグ & ドロップのための API は、新しいドラッグ & ドロップ・サブシステムを使用するわけではなく、既存の Motif API を使用しています。また、共通のデータ転送プロトコルが選択されているので、使用可能な場合には、アプリケーションは新しい API をグローバルに使用しなくても、選択プロトコル・レベルで相互運用できます。

テキストとファイルの転送は、既存のプロトコルを使用します。バッファ転送は、新しいプロトコルを使用します。

ドラッグ & ドロップ処理

基本的なドラッグ & ドロップ処理の実行例を、図 5-1 に示します。

図 5-1 基本的なドラッグ & ドロップ処理

図 5-2 は、オプションのドラッグ & ドロップ処理の変化と操作を示します。破線のボックスは、基本的な処理を示します。実線のボックスは、オプションの変化と操作を示します。

図 5-2 オプションのドラッグ & ドロップの変化と操作

統合アクション・プラン

この節では、アプリケーションと CDE のドラッグ & ドロップとの統合のためのアクション・プランを提案します。

ドラッグ & ドロップ API とサンプル・コードの検討

この章の説明を読んで、ドラッグ & ドロップ API を理解してください。API の基本的な理解ができたら、ドラッグ & ドロップのデモ・プログラム /usr/dt/examples/dtdnd のソースコードを見てください。このコードは、さまざまな API の使い方の例を提供しています。これらの例によって、アプリケーションでドラッグ & ドロップをサポートするために書かなければならないコードの性質と量が理解できます。アクションとデータ型 API の理解にも役立ちます。

可能なドロップ領域についてのアプリケーションの検討

アプリケーションがドラッグ & ドロップの処理を通して受け入れるデータの型を決めます。たとえば、ビットマップ・エディタを作成する場合には、ファイルのドロップをサポートしたいことがあります。アプリケーションにドロップできるデータ型を決めたら、ドロップ領域になるウィジェットを決めます。ビットマップ・エディタの例の場合には、ビットマップ編集領域を、アプリケーション上でファイルをドロップできる唯一の場所として決定できます。この場合、DtDndDropRegister() を使用して、この領域を表すウィジェットを登録し、適切なコールバックを提供します。

ファイル名のドロップの処理は最も簡単なので、ファイル名のドロップの実現から始めてください。この手法をマスターすると、簡単にテキストとバッファのドロップの実現へ進むことができます。

可能なドラッグ・ソースに関するアプリケーションの検討

アプリケーションがドラッグ & ドロップの処理の転送元として許可するデータの型を決めます。ビットマップ・エディタの例の場合、カット & ペーストのアクセラレータとして、現在のビットマップ選択を含んでいるビットマップ・データをドラッグ・ソースにしたいことがあります。アプリケーションからドラッグできるデータ型を決めたら、ドラッグ・ソースになるウィジェットを決めます。ビットマップ・エディタの例の場合、強調表示されているビットマップ選択を含んでいるビットマップ編集領域がドラッグ・ソースの役目を果たすと決定できます。この場合、この領域を表しているウィジェットがドラッグ・ソースになります。

アプリケーションに最もふさわしい、または特有のバッファのドラッグの実現から始めてください。また、アプリケーションの複数起動間の簡単なデータ転送を可能にするために、アプリケーションにバッファをドロップする機能を追加する必要がある場合もあります。

API の概要

この節では、ドラッグ & ドロップのアプリケーション・プログラム・インタフェース (API) の概要を説明します。

DtSvc ライブラリとヘッダ・ファイル

ドラッグ & ドロップ機能は、デスクトップ・サービス・ライブラリ DtSvc で実現されます。ドラッグ & ドロップ API にアクセスするには、ヘッダ・ファイル <Dt/Dnd.h> を組み込み、-lDtSvc をつけてリンクします。

関数

API には 4 つの関数呼び出しがあり、ヘッダ・ファイル Dnd.h の中で宣言されています。これらの関数について、以下の段落で概説します。これらの関数については、後の節で詳しく説明します。

• DtDndDragStart() は、ユーザ・アクションに応答して、ドラッグを開始します。

• DtDndCreateSourceIcon() は、DtDndDragStart() で使用するソース・アイコンを作成します。

• DtDndDropRegister() は、ウィジェットをドロップ領域として登録します。ドロップ領域の登録は、通常はウィジェットが作成された直後に行われますが、いつ行なってもかまいません。

• DtDndDropUnregister() は、以前に登録したウィジェットの登録を解除します。ドロップ領域は、通常は破壊される直前に登録解除されますが、登録後であれば、いつ登録解除してもかまいません。

DtDndContext 構造体

データ転送を処理するには、DtDndContext のデータ構造を使用します。この構造体には、転送プロトコルのためのフィールド、転送される項目数、および転送されるデータ項目の配列が入ります。この構造体の構文の詳細は、DtDndDragStart(3X) および DtDndDropRegister(3X) のマニュアル・ページを参照してください。

プロトコル

プロトコルは、転送データの型を API に知らせるために使用されます。定義済みプロトコルを表 5-6 に示します。

操作

表 5-7 に示すように、ドラッグ・ソースとドロップ領域は 3 つの方法のいずれか 1 つでデータを転送できます。

ドラッグ・ソースの使い方

この節では、ドラッグ・ソースの使い方を説明します。

ドラッグの開始

ドラッグは、2 つの方法のどちらかで開始されます。1 つは、ユーザは、Btransfer (中央マウス・ボタン) を押すことで、ドラッグを開始できます。ボタンが押されるとすぐに、ドラッグが開始されます。もう 1 つは、ユーザは Bselect (左マウス・ボタン)を押しながらカーソルを動かすことによって、ドラッグを開始できます。ユーザがマウスを特定の距離だけ動かすと、ドラッグが開始されます。この距離をドラッグしきい値といい、ピクセル単位で示されます。Bselect のデフォルトのドラッグしきい値は、10 ピクセルです。Btransfer のドラッグしきい値は 0 です。ドラッグしきい値がないので、ポインタを動かすとすぐに、ドラッグが開始されます。Motif スクロール・テキスト・リストおよびテキスト・ウィジェットは、Btransfer と Bselect によってテキスト・ドラッグするためのドラッグ・ソースとして自動的に登録されます。

リストまたはアイコンからのドラッグ

ドラッグ・ソースとして使用できる 2 つの一般的なインタフェース・オブジェクトがあります。すなわち、リストとアイコンです。Motif リスト・ウィジェットは、自動的にテキスト・ドラッグの転送元を示します。他の種類のドラッグが必要な場合には、デフォルトのウィジェット変換を新しい Btn1 と Btn2 変換で無効にすることによって行われます。Motif にはアイコン・ウィジェットはありませんが、通常は描画領域をアイコンのコンテナとして使用します。この場合、ドラッグを開始するために、Btn1Motion のイベント・ハンドラが使用されます。コーディング例の詳細は、/usr/dt/examples/dtdnd のサンプル・コードを参照してください。

ドラッグしきい値

Bselect を使用してドラッグを開始するときには、ウィジェット・イベント・ハンドラまたは変換手順は、ドラッグを開始する前に、10 ピクセルのドラッグしきい値を適用しなければなりません。Btransfer にしきい値はないので、直ちにドラッグが開始されます。

Btransfer または Badjust

スタイル・マネージャの [マウス] カテゴリには、Btn2 (中央マウス・ボタン) が Btransfer として機能するか、それとも Badjust として機能するかを制御する設定があります。この設定は、リソース名 enableBtn1Transfer として格納されます。1 の設定は、Btn2 が Badjust であり、選択を調節することを示します。他の値の設定は、Btn2 が Btransfer であり、ドラッグを開始することを意味します。Btn1 (左マウス・ボタン) は、常にドラッグを開始します。

次の例は、Btn2 が Btransfer か Badjust であるかを決める方法を示します。

Display* display;

int
adjust;
  XtVaGetValues ((Widget)XmGetXmDisplay(display,
	"enableBtn1Transfer", &adjust, 	NULL);

  if (adjust == 1)
 	  /* Btn2 is adjust */
 else
      /* Btn2 is transfer */

ドラッグの開始

共通デスクトップ環境 1.0 アプリケーションは、DtDndDragStart() を呼び出すことによってドラッグを開始します。この関数は、ドラッグを開始するためにデスクトップに特有の準備を行い、XmDragStart() を呼び出します。DtDndDragStart() 関数の形式とパラメータの使用法は、次のとおりです。

Widget DtDndDragStart(
 	Widget				dragSource,
 	XEvent 				*event,
  	DtDndProtocol				protocol,
 	Cardinal				numItems,
 	unsigned char				operations,
 	XtCallbackList 	convertCallback,
 	XtCallbackList dragFinishCallback 	ArgList				argList,
		Cardinal				argCount)

Widget dragSource

ドラッグを始めたイベントを受け取るウィジェット

XEvent *event

ドラッグを始めたボタンが押された、またはボタン・モーション・イベント

DtDndProtocol protocol

データ転送のために使用するプロトコル。プロトコルは、次のいずれか 1 つを使用できます。

DtDND_TEXT_TRANSFER

DtDND_FILENAME_TRANSFER

DtDND_BUFFER_TRANSFER

Cardinal numItems

ドラッグする項目数を指定します。

unsigned char operations

dragSource によってサポートされるオプションを指定します。オプションは、XmDROP_MOVE、XmDROP_COPY、および XmDROP_LINK です。ドラッグ・ソースは、これらの操作の任意の組み合わせをサポートできます。操作の組み合わせを指定するには、or (|) を使用します。たとえば、移動とコピー操作をサポートするには、XmDROP_MOVE | XmDROP_COPY と指定します。

XtCallbackList convertCallback

このコールバックは、ドロップが開始され、ドロップ領域がドラッグ・ソースからデータを要求したときに呼び出されます。convertCallback については、次の節で詳しく説明します。

XtCallbackList dragFinishCallback

このコールバックは、ドラッグ & ドロップ・トランザクションが完了したときに呼び出されます。dragFinishCallback は、dragMotionHandler() をリセットして、ドラッグ & ドロップ・トランザクション時にドラッグ・ソースによって割り当てられたメモリを解放します。

変換コールバックの使い方

変換コールバックは、ドロップが発生すると、ドロップ領域にデータを提供します。変換コールバックの最初のアクションは、callData の中の reason フィールドの確認です。reason が DtCR_CONVERT_DATA または DtCR_CONVERT_DELETE でない場合には、直ちに戻さなければなりません。そうでない場合には、データの変換を続けます。たとえば、ファイル名の変換を処理する場合には、内部のデータ構造体から該当するファイル名を検索して、ファイル・データ・オブジェクトにコピーします。ドラッグ・ソースが移動操作をサポートしている場合には、DELETE ターゲットの変換をサポートする必要があります。すなわち、reason が DtCR_CONVERT_DELETE で convertCallback が呼ばれた場合は、移動されたデータに対して適切な削除アクションを実行します。ファイル転送の場合には、ファイルを削除します。次に、ファイル名の変換と削除を処理する簡単な convertCallback を示します。

void
convertFileCallback(
 	Widget dragContext,
 	XtPointer clientData,
 	XtPointer callData) 
{
 	DtDndConvertCallbackStruct *convertInfo =	(DtDndConvertCallbackStruct*)
  allData;
 	char	 *fileName = (char *) clientData;
  	if (convertInfo->reason == DtCR_DND_CONVERT_DATA) 
   {
		convertInfo->dragData->data.files[0]=
 				XtNewString(fileName); 	
   }

else if (convertInfo->reason == DtCR_DND_CONVERT_DELETE)
   {
		deleteFile(fileName);
 	} else {
 	convertInfo->status = DtDND_FAILURE;
 	}

}

ドロップ領域の使い方

この節では、ドロップ領域の使い方を説明します。

ドロップ領域の登録

一般に、ドロップ領域は、ドロップ領域になるウィジェットが作成された直後に登録します。モード付きドロップ領域にする場合は、ユーザがその上にドロップできるようにするにはウィジェットをドロップ領域として登録し、ユーザがその上にドロップできないようにするには登録を解除します。

Motif テキスト・ウィジェットは、作成されたときに、テキスト用のドロップ領域として自動的に登録されます。二重登録が可能です。テキスト・ウィジェットが、テキストだけでなく、ファイル名など他のデータのドロップも受け入れるようにする場合には、テキスト・ウィジェットをファイル用のドロップ領域としても登録できます。Motif によって提供されるテキスト・ドロップ機能は変わりません。ファイル名 (または他のデータ型) のドロップに対する機能は、その上に重ねられます。

ウィジェットをドロップ領域として登録するには、関数 DtDndDropRegister() を使用します。この関数は、必要に応じて二重登録を処理し、デスクトップに特有の準備を行い、XmDropSiteRegister() を呼び出します。DtDndDropRegister() 関数の形式とパラメータの使用法は、次のとおりです。

void
DtDndDropRegister(
   Widget  dropSite,
 	DtDndProtocol	protocols;
 	unsigned char	operations;
	   XtCallbackList	transferCallback;
 	ArgList	argList;
   Cardinal	argCount)

Widget dropSite

ドロップ領域として登録されるウィジェット

DtDndProtocol protocols

ドロップ領域が使用できるデータ転送プロトコルのリストを指定します。複数のプロトコルの使用を指定するには、or (|) とプロトコルの値を使用します。

unsigned char operations

ドロップ領域によってサポートされる操作。ドロップ領域は、目的の操作の組み合わせに対して or (|) を使用することによって、XmDROP_MOVE、XmDROP_COPY、および XmDROP_LINK の任意の組み合わせをサポートできます。

XtCallbackList transferCallback

この関数は、ドロップ領域にドロップされたデータを受け入れます。転送コールバックについては、次の節で詳しく説明します。

ArgList argList

オプションの引き数リストを指定します。

Cardinal argCount

argList 内の引き数の数を指定します。

転送コールバックの使い方

転送コールバックは、ドロップが発生したときに、ドラッグ・ソースからデータを受け入れます。転送コールバックの最初のアクションは、callData の中の reason フィールドの確認です。reason が DtCR_DND_TRANSFER_DATA ではない場合には、直ちに戻さなければなりません。そうでない場合には、型と reason の中で指定された操作に基づいて、データ転送を続けます。たとえば、ファイルのコピーを処理している場合には、データ構造体からファイル名を検索し、ファイルを開き、その内容をコピーします。ドロップ領域が複数のデータ型をサポートしている場合には、各データ型の転送を適切にサポートする必要があります。

次に、テキストとファイル名のデータ型のコピーをサポートするドロップ領域を描画するための簡単な転送コールバックを示します。

void
	TransferCallback(
 	Widget widget,
 	XtPointer clientData,
 	XtPointer callData)
{
   DtDndTransferCallbackStruct *transferInfo =
				(DtDndTransferCallbackStruct*) callData;
   int ii;

   DtDndcontext * dropData = transferInfo->dropData;
 			return;
   switch dropData->protocol {
 	case DtDND_FILENAME_TRANSFER:
 		for (ii=0; ii < dropData->numItems; ii++) {
 			drawTheString(dropData->data, strings[ii]);
 		}
 		break;
 	case DtDND_TEXT_TRANSFER:
 		for (ii=0; ii<dropData->numItems; ii++){
      drawTheFile(dropData->data.files[ii]);
 		}
      break;
 	default:
			transferInfo->status = DtDND_FAILURE;
     }
}

データ型の使い方

バッファのドロップを受け入れるアプリケーションでは、ドロップされたデータをその型に基づいて異なる方法で処理したいことがあります。データ型を判断するには、データ型 API を使用します。重要なデータ型関数呼び出しは、DtDtsBufferToDataType() と DtDtsBufferToAttributeValue() です。前者はデータのデータ属性名を返し、後者は指定されたデータ属性の値を返します。ドラッグ & ドロップに役立つ属性を、表 5-8 に示します。

詳細は、第 9 章「データ型データベースのアクセス」を参照してください。