Drag-and-Drop Protocol for the X Window System
Changes from previous versions
July 30, 2010
Removed note about using XdndAware as an initial filter. Since it must be set only on top level windows, it is too complicated to keep track of all the data types that all the child windows accept.
June 17, 2009
Added scrolling to XdndPosition. Changed recommendation from a hysteretic scroll zone outside a widget to simple scroll zones inside a widget.
May 21, 2009
Added note on the importance of sending periodic XdndPosition messages when the cursor is not moving. Without this, the target cannot scroll smoothly.
December 25, 2002
Version 5 adds additional information to the XdndFinished message in order to allow the Java DND API to be implemented on top of XDND. (Thanks to Danila A. Sinopalnikov for working out the details.)
August 31, 2002
Added requirement to File Dragging protocol. The user name must be provided via the new text/x-xdnd-username data type.
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.
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.