The goal of Drag-and-Drop is to allow users to quickly and easily move data from one program to another. This requires that all programs use the same protocol and the same data types.
An especially important data type is the file. All programs should accept dropped files where ever possible in order to allow users to use a graphical file manager to access their data.
Since UNIX provides powerful networking support, and X allows the user to display file managers from different machines on the same screen, one must actually use the full URL, including the host name, for each file that is dragged. The default format is the standard "file://host/path". If a particular protocol, e.g., HTTP or FTP, is appropriate, then this should be used, e.g., http:// or ftp:// instead of file://. (scp should be used if no specific protocol is specified.) Simple programs can reject files that are not available locally, while sophisticated programs can use a method such as ftp or rcp/scp to retrieve them. (The sample implementation includes code to convert between URL's and local file names.)
The data type of a URL or list of URL's is text/uri-list. It is an error to not include the host name (the value returned by gethostname()) as part of the URL. (Consider the case when the user drags a file to the trash. Without the host name, this could delete a file from the wrong computer!)
It is also an error to not provide the user name (the value returned by getpwuid(getuid())->pw_name) via the separate data type text/x-xdnd-username. As an example, when the user drags a file from one window to another, it will not work if the user is logged in to the source and destination with two different user names. However, since there are many existing implementations that do not provide text/x-xdnd-username, implementors are advised that they should assume a reasonable default, e.g., the same user name for scp or anonymous for ftp, if text/x-xdnd-username is not available. (The format file://user@host/path/file was avoided in order to be compatible with all the existing implementations.)
Note that, in general, the source should not provide any types other than text/uri-list and text/x-xdnd-username. This is because anything on the file system can be dragged: plain text, HTML, images, binary executables, or even directories. The only type that encompasses all these is text/uri-list. All of these can even be dragged at the same time. It is the target's responsibility to sort out what was dropped and do something reasonable.
In order for file managers to be able to communicate with each other, one also needs to be able to specify that the target perform particular actions on the dropped files. The predefined actions XdndActionCopy, XdndActionMove, and XdndActionLink should be used for this purpose. Targets other than file managers should respond with XdndActionPrivate to indicate that they will do something else with the files, e.g. search them, compile them, etc. File managers should provide visual feedback in the cursor if the target accepts the requested action. (e.g. display a small arrow if the target accepts XdndActionLink)
It is important to note that file managers will often have to block until receiving XdndFinished. As an example, if the user drags a file from a local directory to a directory opened via ftp, then the user cannot be allowed to delete or move the file until the ftp transfer is complete. (Of course, the program should not block off more than these two directories.)
Dragging files to a trashcan is a special case that must be handled separately. In this case, the most natural model is for the user to set the trashcan to either store, incinerate, or ask mode and then for the trashcan to respond with XdndActionPrivate. The best way for the trashcan to tell the user about its current setting is to change its appearance.
When dragging files from a file manager window, the default action should be XdndActionMove if the target is the same disk, and XdndActionCopy otherwise. When dragging files from other programs (e.g. a list of files to search or compile), XdndActionPrivate should be the default because it isn't clear what the user intends to do. File managers should treat XdndActionPrivate as if it were XdndActionAsk and use the actions that the file manager itself supports.
Last updated on February 22, 2000
Back to the main page.