Drag-and-Drop Protocol for the X Window System

Examples of using Drag-and-Drop

 

Drag-and-Drop is currently the closest operation we have to "do what I mean."  It is therefore very important to pick the most natural operation to be the default.

 

Dragging text (and almost anything else)

 

Even though this is the simplest example of DND, it is still non-trivial.

 

When the user drags text within a document, the natural default action is move.  Since users may also want to use DND to duplicate text, one needs to define a modifier key (e.g. Meta) for this.  One cannot use a different mouse button since X users expect middle-click to mean "paste" and right-click to mean "extend the current selection."  (the de-facto standard set by xterm)

 

On the other hand, when the user drags text to another document, the natural default action is copy since the two documents are unrelated.  This is also the safest alternative because the original data will not be lost, regardless of what the target does after the drop.  It is reasonable to provide move as well, but not as the default.

 

A special case is a compound document where different parts are managed by different applications.  In this case, move is the natural default action because the user perceives it to be a single document.  Users will still expect copy to be the default when text is dragged to a different document.  (Since the X window ID of the source is included in the XdndPosition message, it is possible to tell if the drop is on a different part of the same document.)

 

When two documents cooperate (e.g. linked spreadsheets), link is an appropriate option, but it should not be the default.

 

Dragging files

 

This is discussed in depth on a separate page.  Here, it is sufficient to note that, while many programs might accept drops (e.g. a program that builds a Makefile), file managers are the only programs that one would expect to modify the actual file system.  Thus, the appropriate design is for everybody to accept the data type text/uri-list, and for file managers to internally use the action (XdndActionCopy, XdndActionMove, XdndActionLink) to tell themselves what the user wants done.  All other programs that accept text/uri-list should return XdndActionPrivate.

 

Trashcans

 

Trashcans are simply a convenient extension of file managers to provide a familiar metaphor for deleting files.  They are mentioned here because they introduce an interesting design twist.  The most convenient way for a trashcan to work is for the user to first set it to either store or incinerate and then drop files on it forever.  This means that the target is deciding the action instead of the source.  The trashcan accepts text/uri-list (from any source) and decides whether to move it to ~/.trash or to delete it.  (XdndActionAsk can be used to tell the trashcan that it should ask after a particular drop.)

 

The best way to tell the user what will happen after a drop is for the trashcan to change its appearance based on the user's setting.

 

More Examples

 

If you have an interesting example, please let us know.