top of page

Example walk-through

 

Note: Parenthesized numbers in bold-face are the number of packets sent to or from the server.

 

Step 0:

 

Before the drag begins, the source creates a window property XdndDirectSave on itself of type text/plain (including the charset attribute, if necessary) that contains the file name (without a path) in which the user wants to save.

 

The source should specify the action XdndActionDirectSave.

 

When the file manager receives XdndPosition, it should only accept the drop if the target directory is writable.  If the mouse is over the icon or name of a writable directory, this is the target, and the icon should be highlighted.  Otherwise, the target is the directory whose contents are displayed in the window. Since continuous feedback is provided to the source, this will not cause problems even if the window's directory is not writable and some of its subdirectories are writable.

 

Step 1:

 

When the file manager received XdndDrop, it should first check for XdndDirectSave. If this is not provided, it should fall back on text/uri-list.

 

If it finds the XdndDirectSave target, it retrieves the data from the source window's XdndDirectSave property (2), converts it to a URL (e.g. name → file://host/path/name), places this in the XdndDirectSave property (2), changes the type to match the character set (if necessary), and requests XdndDirectSave from the source. (7)

 

Step 2:

 

The source receives the request for XdndDirectSave, retrieves the data from its XdndDirectSave property (2), and tries to save the data to the specified location.

 

If successful, it responds to the target's request with data of type XA_STRING containing the single character S (0x53), indicating success.  It then waits for the file manager to respond further.

 

If it would like to use the specified location but cannot because it is on a different machine, it responds with data of type XA_STRING containing the single character F (0x46), indicating failure.  It then waits for the file manager to respond further.

 

If it refuses to save the data in the specified location (e.g. it does not allow saving on a different machine because the file's contents are not relocatable), it responds with data of type XA_STRING containing the single character E (0x45), indicating an error.

 

Step 3:

 

The file manager receives the result.

 

If it receives S, it refreshes its display to show the new file and then sends XdndFinished.

 

If it receives F, it checks for the data type application/octet-stream.  If this is available, it retrieves it and tries to save the file itself.  If successful, it refreshes its display.  Otherwise, it changes the source window's XdndDirectSave property to zero length to indicate failure. (1)  It then sends XdndFinished.

 

If it receives E, it sends XdndFinished.

 

Step 4:

 

The source receives XdndFinished.

 

If it sent S or F, it checks its XdndDirectSave property.  If this is not empty, the source updates the file path and name that it stores and clears its "needs save" flag.  (The property can be empty in either case, as explained in the Notes section.)

 

Regardless of what it sent or received, it must delete the XdndDirectSave property when it is finished.  (This can be done in the XGetWindowProperty() call.)

 

Next >>

 

bottom of page