Dozing
creation with digital methods

訳注：訳注は全て赤い文字で示してあります。リンクはページの編成が見にくくなるので全て解除してあります。代わりに下線を引いてありますので、そちらは原文の方を参照してください

　

Xウィンドウ・システムのためのDrag-and-Dropプロトコル

イントロダクション

今日ドラッグ・アンド・ドロップ（DND）は商用品質のアプリケーションについて必要だと考えられます。ほとんどのオペレーティング・システムにおいては、DNDのサポートが組み込まれており、そのために、誰でもそれを使用し、また、プログラムはすべて互いと通信することができます。

しかしながら、Xにおいては標準がなく、様々なグループが自分のプロトコルを開発し、結果、1つのプロトコル用に書かれたプログラムは、異なるプロトコル用に書かれたプログラムと通信することができません。明らかに、これは、任意のプログラムから他のプログラムへデータをドラッグするという基本的な要求を満たしていません。

必要な事は、DNDによって全てのプログラムがデータを交換することができ、それを誰もが使うことのできる1つのプロトコルです。（Xのセレクションのメカニズムは、誰でもクリップボードによってデータを交換することができるという事を保証します。）

そのようなプロトコルのための基礎的な必要条件は、ドラッグ中にユーザへ視覚的なフィードバックを供給し、ドラッグ元が持っている全てのデータフォーマットの中から、ドラッグ先はどんなデータフォーマットも選べられることです。さらに、視覚的なフィードバックがユーザのアクションより遅れないように効率的でなければなりません。また、それはデッドロックや競合状態、および非同期システムにある他の危険から安全でなければなりません。

現在のバージョン：4
最終更新日：2000年11月21日

他のDNDプロトコルへの比較

XDNDプロトコルの支持者

定義

ソースとはデータを供給するウィンドウです。

ターゲットとはカーソルが上にあるウィンドウあり、もしボタンが離されればドロップを受け取ります。

Xlibのマニュアルで述べられているXSelectionに精通していなければなりません。それはXlibマニュアルのVolume0、付録L、およびVolume1、Chapter10で述べられています。

全てのデータ・タイプおよびアクションはそれを関連づけたXAtomによって参照されます。データ・タイプのアトム名は全て小文字のMIMEタイプに対応します。（MIMEについてのRFCは： 2045 、 2046 、 2047 、 2048 、 2049 ）

このドキュメントの中で言及された定数はすべてXアトムの文字列名で、それを示すために大文字化されています。これは、ハードコーディングされた値（それらはグローバルに登録される）の必要を回避します。

一通りの例

注意： ボールドで装飾してある括弧内の数は、サーバへ、もしくはサーバから送られたパケットの数です。

ステップ0：

ウィンドウは、ウィンドウプロパティXdndAwareの作成により、それらがXDNDプロトコルをサポートすると知らせます。

ステップ1：

ドラッグが始まる場合、ソースはXdndSelectionの所有権をとります。

マウスがXDNDをサポートするウィンドウに入る場合（ウィンドウプロパティの検索、平均8）、ソースは、タイプXdndEnterのClientMessageを送ります（2）。それは使用するプロトコル・バージョン、およびソースがサポートしているデータ・タイプを含んでいます。

ある拡張は他のウィンドウにドロップすることを可能にするために開発されています。

ステップ2：

ターゲットはXdndEnterを受け取ります。

ClientMessageは、データ・タイプのためのスペースを3つだけ持っています。したがって、ソースがこれを越える数をサポートする場合、ターゲットは利用可能なタイプのリストを得るためにソースウィンドウからプロパティXdndTypeListを取得しなければなりません。（2）

ステップ3：

ソースは、タイプXdndPositionのClientMessageを送ります。（2）これは、ターゲットにマウスの位置とユーザが要求したアクションを伝えます。

ステップ4：

ターゲットはXdndPositionを受け取ります。

ターゲットウィンドウは、マウスがどのウィジェットにあるか決定しなければなりません。そしてそれがドロップを受け付けるかどうか尋ねなければなりません。効率については、ターゲットウィンドウは、ウィジェットがドロップを受け付けるか受け付けないかに関わらず、マウスの位置を追うべきです。そしてもしアクションが変化するか、マウスが別のウィジェットの部分に入るときに再び尋ねるべきです。一旦ウィジェットがドロップを受け付け、できるだけアクションを同じのままにし、マウスが同じ部分で残るとき、適切ならば、データが挿入される所をユーザに示すために再描画することができるよう、ウィジェットは全てのXdndPositionメッセージを受け取ります。

それがドロップを受け付けるかどうか決定するために、ターゲットウィジェットはXdndEnterメッセージからのタイプリストを調べ、XdndPositionメッセージからの要求されるアクションを調べます。

要求されたアクションを実行することができない場合、それはXdndActionCopyあるいはXdndActionPrivateのいずれかを返すことができます。これらのどちらも可能でない場合、それはドロップを拒絶するべきです。

それがデータ自体を見る必要がある場合、XdndSelectionのためにXConvertSelection()を呼び出し、興味を持っているデータ・タイプ、与えられたタイムスタンプを呼び出します。（7）必要ならば、それは二度以上行うことができます。

ドロップを受け付ける場合、ユーザに知らせるためにその境界をハイライトすべきです。もしデータを受け取る場合、実際のドロップが起こったときに再び受け取る必要がなくなるように、それをキャッシュすべきです。

ステップ5：

ターゲットは、タイプXdndStatusのClientMessageを送ります。（2）これは、ドロップを受け付けてもそうでなくてもソースに伝え、もし受け付けるなら起こったアクションを伝えます。さらに、それは「この外にマウスが移動するまで他にXdndPositionメッセージを送るな」という意味の長方形を含んでいます。

ステップ6：

ソースはXdndStatusを受け取ります。ユーザの要求しているアクションが実行されるかどうかを示すカーソル、その形状を変更するために、XdndStatusアクションを使用することができます。

マウスが与えられた長方形の外へ移動する場合、ステップ3へ戻ります。

XdndPositionメッセージは、通常MotionNotifyのイベントが引き金となって起きます。しかしながら、ソースがXdndStatusを待っている間にマウスが動く場合、ソースは新しいマウス位置をキャッシュし、XdndStatusメッセージを受け取るとすぐ、別のXdndPositionメッセージを生成しなければなりません。（サーバ-ターゲット間の接続がサーバー-ソース間の接続よりはるかに遅い場合、これは必要になります。）

ステップ7:

マウスがウィンドウから離れる場合、ソースはタイプXdndLeaveのClientMessageを送ります。（2）

マウスボタンがウィンドウで放される場合、ソースは最後のXdndStatusメッセージ(必要ならば)を待ち、次に、最後のXdndStatusの中の「accept」フラグによって、タイプXdndLeaveあるいはXdndDropのClientMessageを送ります。（2）

もしソースがXdndStatusメッセージを受け取らなければ、待たずにXdndLeaveを送るべきです。

ソースが理にかなった時間以内で期待されたXdndStatusを受け取らない場合、XdndLeaveを送るべきです。XdndStatusを待っている間、ソースをブロックすることができますが、ターゲットがデータを検討することができるように、少なくともSelectionRequestのイベントは処理しなければなりません。

ステップ8:

ターゲットがXdndLeaveを受け取る場合、どんな貯えられたデータも解放し、全体の出来事を忘れます。

ターゲットがXdndDropを受け取り、それを受け付けるであろう場合、与えられたタイムスタンプを使って（まだキャッシュされていない場合）データを取り出すためにXConvertSelection( )を最初に使用します。（7）その後、それは、XdndStatusによって知らされた最後のアクションおよびマウス位置に関連するデータを使用します。（遅いネットワーク上では、ドロップの位置を、ユーザに与えられた視覚的なフィードバックと一致するようにします。)一旦終了すれば、XdndFinishedを送ります。

ターゲットがXdndDropを受け取り、それを受け付けないであろう場合、XdndFinishedを送り、それをXdndLeaveとして扱います。

理論

このプロトコルのすべての部分は目的に役立ちます。

XdndAware

ユーザがDNDによって任意のアプリケーションから他のアプリケーションへデータを転送することができるために、XDNDバージョンNをサポートする全てのアプリケーションは、すべての前のバージョン（3からN-1）をサポートしなければなりません。XdndAwareプロパティは、目標にサポートされた最も高いバージョン番号（Nt）を提供します。ソースがバージョンNsまでをサポートする場合、実際に使用されるバージョンはmin(Ns , Nt)です。これはXdndEnterメッセージの中で送られたバージョンです。どんなメッセージも実際に送られる前に XdndAwareがこの計算をする事を可能にします。これに注目することは重要です。

技術的な詳細セクションの中で説明されるように、プロパティはターゲットによって受け付けるタイプのリストを含むことができるので、プロパティは余分なフィルタの役割も果たすことができます。

さらに、スクロールすること(下記の注意セクションを参照)また、他のDNDプロトコルと共存すること（XdndAwareが存在しない場合に、他の何かを試みることができるので）については、それはクリティカルでもあり、ターゲットのXDNDバージョンをチェックさせ、その後に期待したXdndStatusメッセージを受け取らせるので、デバッグするのに役立ちます。

Xセレクション

XConvertSelection()を使用によって、クリップボードとドラッグアンドドロップの両方のために同じデータ転換コードを使用することができます。ターゲットがタイプ「MULTIPLE」を要求する場合、あるいはソースがデータを増大的に送る（タイプ「INCR」）ことを強要する場合、これは特に大きな救済です。また、メッセージの主な処理の流れと無関係なデータをチェックさせ、そのようにして最初にXdndStatusが正しく「はい」、「いいえ」と報告します。

XdndSelectionの使用によって、ドロップされたデータは、XA_PRIMARYに格納されたクリップボード・データに影響を与えません。

XConvertSelection()を使うことは、データの転送が完了する前にユーザが他の何かをドラッグすることができる問題を持っています。しかしながら、Xのクリップボードは同じ問題を持っており、したがって、これがユーザに追加の制約を課さず、下のXdndFinishedメッセージの議論で説明されているように、それを回避することができます。

アクション

データ・タイプからアクションを別々に指定することは、Nデータ・タイプおよびMアクション用のN×Mアトムを定義するのを回避できます。ユーザは起こるであろうことの全てのコントロールを行うに違いないので、ちょうど1つのアクションはソースによって指定されます。これは、アクションがドラッグ中に変わることを可能にし、それはXdndPositionメッセージの中で渡されます。（例えば、ユーザがモデファイヤーキーを押すかリリースするかでアクションが変わるような場合）ターゲットによって受け付けられたアクションは、ソースがカーソル中のフィードバックを行なうことを可能にするよう、XdndStatusメッセージの中でソースへ渡されます。

特別のアクションXdndActionAskは、ドロップが起こった後に何を行うかユーザに尋ねるべきだと、ターゲットに伝えます。これは、Windows95®の中で、ファイルマネージャがユーザに移動するかコピーするかリンクを作るかキャンセルするか尋ねるような、右ドラッグにより得られる効果を実装することを可能にします。アクションのリストは、ソースウィンドウ上にあるXdndActionListプロパティ、およびソースウィンドウ上にあるXdndActionDescriptionプロパティから得られたユーザに見せるための各々のアクション毎の記述、その両方から得られます。このときデータを取得する前に、さらにXdndFinishedを送る前に、ユーザが尋ねられるべきである、ということに注意してください。

特別のアクションXdndActionPrivateは、ターゲットはソースの理解できない何かをしようとしていることと、データのコピー以外をソースに要求しないということを、ソースに伝えます。

メッセージ

XdndEnter メッセージはセッションを開始して、ターゲットにローカル変数を準備する機会を与えます。それはターゲットウィンドウ座標をルートウィンドウ座標へ変換する等のようなものです。また、ターゲットが XdndSelection のために XconvertSelection( ) を呼ぶ必要がないように、XdndEnter はサポートされているデータ・タイプのリストを提供します。

XdndPosition メッセージはマウスの位置を提供します。それはターゲットがそれ自体を適切に描き直すためにXのサーバーを尋ねる必要がないようにするためです。Xはソースウィンドウでグラブされることをマウスカーソルにさせるので、ターゲットがマウス位置を得る他の信頼できる方法はありません。したがって、ソースウィンドウだけがイベントを受け取るでしょう。データがどこに挿入されるか示すために自分を更新しなければならないので、ターゲットはマウス位置を必要とします。これは特に、テキストエディタ、スプレッド・シート、ファイル・マネージャーでは重要です。

XdndPositionメッセージ中のタイムスタンプは、正しいデータを受け取ることを保証するために、XConvertSelection( ) の引数へ与えなければなりません。

XdndStatus メッセージはソース（例えば、それはカーソルを変更したいと思うかもしれません）へフィードバックを供給し、ネットワーク接続が遅い場合XdndPositionメッセージが積もらないと保証します。

XdndLeave メッセージはセッションを取り消します。

XdndDrop メッセージは、ドロップを続けるようにターゲットに命じます。正しいデータを受け取る事を保証するために、タイムスタンプは XConvertSelection( ) の引数に与えなえればなりません。

XdndFinished メッセージは、ターゲットがドロップを終了するか、もはやデータを必要としないとソースに伝えます。これは、ソースが3つの異なる振る舞いのうちのどんな1つも実行することを可能にします:

よく機能しないプログラムに対して保護すること

XdndEnterメッセージ中のバージョン番号が、ターゲットがサポートることができるものより高い場合、ターゲットはソースを無視するべきです。

ソースおよびターゲットが互いからXDNDメッセージを受け取っている間、他のウィンドウからのXDNDメッセージをすべて無視するべきです。

DNDがアクティブな間に一方のアプリケーションがクラッシュする場合、もう一方のアプリケーションはBadWindowエラーによるクラッシュを回避しなければなりません。これを実行するためのただ一つの安全策は、XSetErrorHandler( ) でエラーハンドラをインストールによって実際のエラーをキャッチすることです。さらに、ソースがXdndStatusの受信とXdndPositionの送信の間にクラッシュする場合、ターゲットが別のXdndPositionを永久に待たないように、ターゲットは DestroyNotify のイベントを監視しなければなりません。

上に議論されるように、ソースはターゲットがXdndFinishedを送らない場合にロックすることを回避するように気をつけなければなりません。

Notes

ソースとターゲットが同じ場合、ドロップはソースウィンドウのまわりの領域内でヒステリシス（訳注：ドラッグ中にウィンドウを出るか出ないかぐらいに行くと、自動的にスクロールするやつ、Winのエクスプローラみたいな）であるべきです。（例えば50のピクセル境界）ドロップを喜んで受け付ける別のウィジェットへマウスが移動しない限り、ターゲットはソースに留まります。これは、ユーザがソースの見えない部分へデータをドロップする事をとても簡単にします。なぜなら、ルートウィンドウ上や、はぐれたxterm上へマウスを動かす事はソースのスクロールを引き起こすからです。ルートウィンドウや、はぐれたxterm、特にウィンドウマネージャで作られるウィンドウ境界は無視されるので、XdndAwareプロパティはヒステリシスを可能にします。

私たちは、様々な場面でDNDが働くかもしれないということを示すために例を集めています。テキストのドラッグは、text/plainやtext/enrichedを含めて、いくつかの有名なフォーマットがあるので、簡単です。ファイルのドラッグは少なくとも同じぐらい重要です。

さらに、私たちは、ドロップをルートウィンドウやXDNDをサポートしないウィンドウへドロップを可能にする拡張を開発しました。

ターゲットはデータだけでなくデータの位置も得なければならないので、XdndActionLinkは、単一のプログラム内や、協調するプログラム間でのみ意味をなします。他のすべての場合では、ターゲットはXdndStatusメッセージ中のXdndActionCopyあるいはXdndActionPrivateで答えるべきです。

他方で、XdndActionAskは、関連してないプログラムと協調するプログラムの間で等しく良い意味をなします。しかしながら、ソースおよびターゲットが無関係な場合、アクションのリストをソースへ尋ねる代わりに、データを取得した後に、実行することができるアクションのリストをデータから独力で得る、という事をターゲットは選択するかもしれません。

また、マウスドラッグをデバウンスしなければならないことを覚えておいてください。ユーザが何かを選択するためにクリックする間、ほんの2、3のピクセルがマウスで移動してしまう事は、ユーザが少し不器用であれば、ドラッグを始めようとする事よりはるかにありそうです。典型的な閾値は3ピクセルです。

私の石鹸箱の上で起きること （訳注：よくわからない慣用表現なので直訳です）

私の見解およびプログラムの中で、すべきでない事は、ドラッグ中にカーソルを変更することです、何故なら、これがユーザに最も一貫した絵を供給するからです。ユーザは、現在のターゲットがドロップを受け付けるかどうかにかかわらず、同じデータを常にドラッグしています。ドロップを受け付けるかどうか示すために変わるべきのはターゲットです。

しかし、あなたがマイクロソフトに不満を言いたいなら、カーソルを変更しなければなりません。相変わらずマイクロソフトはそれは昔のままです・・・・・

サイドノートとして、彼の本の253ページの、 顔に関して、アラン・クーパーは心から同意します。

私が支持する1つの例外は、要求されたアクションが実行されるだろうことを示すために、XdndActionPrivateの代わりに、カーソルに小さなシンボルを加える事です。例に関しては、ファイルのドラッグページを参照してください。

最適化

ソースとターゲットウィンドウが同じアプリケーションの一部である場合、Xクライアント・メッセージを送ることは時間と帯域幅の浪費です。もしプログラムとサーバーが異なるマシン上にある場合は特にそうです。したがって、実装においては「ソース＝ターゲット」と「ソースとターゲットは同じアプリケーション上にある」という特別なケースを検知し、関数呼び出しによってそれらを扱うべきです。

上記の場合に XConvertSelection( ) を呼ぶのを回避するために。

XdndEnterメッセージにリストされた3つのタイプの中で探しているものが見つかった場合は、ターゲットはソースウィンドウからXdndTypeListを取得する必要がありません。

マウスが静止している場合、XdndPositionメッセージを送ることは無意味です。

ソースからサーバーまで不必要なメッセージを回避するために、ターゲットかステータス(受理とアクション)が変わる場合、カーソルを変更するのみにすべきです。

不運にも、ウィンドウのオーバーラップのために XTranslateCoordinates() を頻繁に呼ぶことを回避することができません。

技術的な詳細

現在のバージョン： 4

下に言及された全ての定数は、Xのアトムの文字列名で、大文字化して示されています。これは、ハードコーディングされたグローバルな登録を必要とするであろう値の必要を回避します。

アトムとプロパティ

XdndAware

このウィンドウプロパティはタイプXA_ATOMでなければなりません。また、サポートしている最も高いバージョン番号を含んでいなければなりません。（バージョン番号は0から始まり、最も高いバージョン番号は0xFFです。というのは、XdndEnterメッセージの中でそれに分配されているのは1バイトだけだからです。もし3か月ごとに1つの新しいバージョンがあれば、それは非常に急速な変更ですが、これは64年続くでしょう。）

プロパティは、ドロップを受け付けることができるウィジェットを含んでいる、各トップレベルウィンドウに設定されていなければなりません。（バージョン3において新しい。）プロパティはサブウィンドウ上にセットされてはなりません。ターゲットは適切なウィジェットにメッセージを配送しなければなりません。ウィンドウマネージャがウィンドウの余分なレイヤー（訳注：デコレーション？）をしばしば挿入するので、XTranslateCoordinates() を使ってサブウィンドウ木を下へ探索することをしばしば要求します。

XdndSelection

これは、ターゲットがドラッグ過程中にデータを検討したい場合、およびドロップの後にデータを取得したい場合、使用されるXのセレクションの名前です。

データ・タイプ

データ・タイプはすべて対応するXのアトムによって参照されます。アトム名はMIMEタイプ に対応しています。それは全て小文字です。（MIMEのためのRFCは： 2045、 2046、 2047、 2048、 2049）

テキストについては、文字セット属性をMIMEタイプによって追加することができます。（例えば、日本語＝＞text/plain；文字セット＝ISO-2022-JP ）文字セット属性が指定されない場合、それはISO-8859-1であると仮定されます。（バージョン4において新しい。）

どんなデータ・タイプもINCRプロトコルによって転送されるかもしれないという事に注意してください。

XdndTypeList

ソースが3つを越えるデータ・タイプをサポートする場合、このウィンドウプロパティはソースウィンドウ上でセットされなければなりません。また、そのタイプはXA_ATOMでなければなりません。さらに、サポートしているデータ・タイプのすべてのリストを含まなければなりません。

アクション （バージョン2において新しい。）

全てのアクションは、それらに対応するXのアトムによって参照されます。定義済みのアクションは次の通りです。

XdndActionプレフィックスは将来の拡張のために予約されています。しかし、ソースおよびターゲットの両方がそれを認識し、それが意味する事が一致している限り、他のアクションのために他の名前も使用することができます。定義済みのアトム none はアクションとして使用してはいけません。

デフォルトはXdndActionCopyです。また、これはバージョン0あるいは1を使用する場合に、アクションであると仮定されます。

一般に、XdndActionMoveは、最初にデータを要求してから次にXのセレクションプロトコルで定義された特別なターゲットDELETEによって実装されます。（ファイル・マネージャーは明らかに mv かそれと同等なものとして使用するでしょう。）DELETEはXdndFinishedの前に送られるべきです。

より詳細に関しては理論とNotesのセクションを参照してください。

XdndActionList （バージョン2において新しい。）

ソースがXdndActionAskを送る場合、このウィンドウプロパティはソースウィンドウ上でセットされなければなりません。また、タイプXA_ATOMでなければなりません。さらに、サポートしているすべてのアクションのリストを含んでいなければなりません。ユーザがとても頻繁に選択肢の変更する必要がないように、最初のものはデフォルトのものにすべきです。

XdndActionDescription （バージョン2において新しい。）

ソースがXdndActionAskを送る場合、このウィンドウプロパティはソースウィンドウ上でセットされなければなりません。また、タイプXA_STRINGでなければなりません。さらに、ユーザが選択肢を選ぶときにターゲットが表示すべき項目を、null によって分離されたASCII 文字列で格納していなければなりません。 これらの文字列はXdndActionListプロパティ中のアトムと同じ順番でなければなりません。

ドロップの実行を取り消す選択肢は、Cancelボタンによって、ダイアログ中にユーザへ表示されることでもたらされます。しかし、XdndActionListに含まれるべきではありません。

XdndProxy （バージョン4において新しい。）

このウィンドウプロパティが存在する場合、それはタイプXA_WINDOWでなければなりません。また、XdndAwareがあるかどうかをチェックされる、全てのクライアントメッセージ受信する等の、プロキシウィンドウのIDを含まなければなりません。プロキシウィンドウを正しく機能させるために、クライアントメッセージの適切なフィールド、 window あるいは data.l[0]は、メッセージを受け取っているプロキシウィンドウではなく、マウスが位置するウィンドウのIDを含んでいなければなりません。プロキシウィンドウが使用されるべきただ一つの場所は、XdndAwareをチェックする場合、そして XSendEvent ( ) の呼び出しの中です。

プロキシウィンドウは、それ自身を指すためにXdndProxyプロパティセットを持っていなければなりません。そうしない場合、あるいはプロキシウィンドウが全く存在しない場合、クラッシュの後にそれが残される仮定のもとでXdndProxyを無視するべきです。

クライアント・メッセージ

注意： すべての未使用のフラグは全てのメッセージの中で0にセットされなければなりません。これはバージョン番号をインクリメントせずに、新しいフラグを定義することを可能にします。

XdndEnter

マウスがXDNDをサポートするウィンドウに入るとき、ソースからターゲットへ送られます。

XdndPosition

マウス位置を供給するためにソースからターゲットへ送られます。

XdndStatus

フィードバックを供給するためにターゲットからソースへ送られます。これはドロップを受け付けるか受け付けないか、もし受け付けるならどのアクションが起こったかを送ります。

XdndLeave

ドロップをキャンセルするためにソースからターゲットへ送られます。

XdndDrop

ドロップが完了した時にソースからターゲットへ送られます。

XdndFinished （バージョン2において新しい。）

ターゲットはもはやソースにアクセスする必要がなくなったので、ソースはデータを捨てることができる、という事を示すために、ターゲットからソースへ送られます。

Sample implementation

If you are interested in supporting this protocol, but daunted by having to start from scratch, you can obtain sample C++ code via anonymous ftp. This code may be used under any license.

Paul Sheer has implemented XDND v2 in C as a generic library. The files are xdnd.c and xdnd.h

If you use a different language, please consider donating your code for others to look at.

We also have a binary that you can use to test interoperability between a correct implementation and your implementation.

While implementing this protocol, you may find it very useful to use the programs xlsatoms to list all the atoms that the server knows about, xprop to list all the properties on a particular window, and xscope to study the timing of events.

Even if you implement XDND from scratch, we would appreciate it if your distribution included some sort of documentation that states clearly that you are supporting this protocol and provides a reference to this web page. This will help get the snowball rolling. The more programs that support the same protocol, the more useful Drag-and-Drop will be for the users. If you tell us that you support the protocol, we will also add you to the list of supporters.

Changes from previous versions

November 21, 2000:

Thanks to Daniel Biddle for pointing out that the MIME types should be specified in the format ISO-8859-1, not iso8859-1.

October 26, 2000:

Minor modifications to actions required by File Dragging protocol.

February 22, 2000:

Added additional notes about why the host name must always be included when dragging files.

June 7, 1999:

Version 4 adds XdndProxy window property to support the new protocol for dropping on the root window.

Rewrote the protocol for dropping on the root window to conform to the latest implementations.

Added note in Technical Details section about how to specify the character set for text.

Created Direct Save (XDS) protocol layered on top of XDND.

December 1, 1998:

Rewrote the protocol for dropping on the root window to conform to the latest implementations.

September 19, 1998:

The File Dragging protocol now uses the well established text/uri-list instead of url/url.

Added note to Optimization section about caching the window stack.

September 7, 1998:

Version 3 changes the way XdndAware is handled. To reduce the number of XTranslateCoordinates() calls to the X server and to make life easier for programs that use multiple X windows per widget, XdndAware must now be placed on the top-level X window, not on subwindows. This change is unfortunately incompatible with previous versions. However, since there are still relatively few programs that have been released with XDND support, the specification has simply been adjusted so XDND compliance only requires supporting version 3 and up. (This will never happen again!)

In addition, Jeroen van der Zijp has invented an extension that allows dropping onto windows that do not support XDND, and Arnt Gulbrandsen has developed a way to drop on the root window.

August 17, 1998:

Version 2 adds the following features:
  • The concept of an action. Previously, only copy was supported. Now, the source can specify any action, and the target can either accept it or fall back on copy or private. The predefined actions are XdndActionCopy (the default), XdndActionMove, XdndActionLink, XdndActionAsk, and XdndActionPrivate. Ask tells the target to get a list of acceptable actions from the source's XdndActionList and XdndActionDescription window properties and then ask the user which one to perform.

  • The target is required to send XdndFinished. (Yes, I caved in :) However, if the source blocks, it must be prepared to time out in case the target is malfunctioning. Ideally, the source will not need to block because it will keep a history of past selections. The timestamp in XdndDrop allows the source to safely avoid both blocking and keeping a history by simply rejecting outdated requests.

    Part of the reason for adding XdndFinished is that this allows XDND to be used with higher level API's (e.g. JavaBeans) that require notification of the end of the operation.

With these new features, the File Dragging protocol becomes much simpler.

Added page of supporters.

February 25, 1998:

Added examples of how XDND fits into the larger picture of cooperating applications.

February 24, 1998:

Added trashcan discussion to the File Dragging protocol.

February 2, 1998:

Version 0 has a hole. If the user begins a second drag from the same source before the data has been transferred to the first target (over a really slow network, obviously), then the first target may get the wrong data. Thanks to Donal K. Fellows for pointing this out.

Version 1 fixes this by adding a time stamp to XdndPosition and XdndDrop which must be used when requesting the data. This way, if the user quickly begins a second drag, the first target will at least get no data instead of the wrong data.

Please refer to the Theory section for a more complete discussion and the reasons why this was not fixed by adding a "drop finished" message.

January 28, 1998:

Added comparison to Xde.

Acknowledgements

This protocol was developed by John Lindal at New Planet Software, with help from Glenn Bach and lots of feedback from Arnt Gulbrandsen at Troll Tech and Owen Taylor of GTK+ and input from Elliot Lee at Red Hat Software.

<noembed><noembed><noembed>