top of page

Notes

 

Given that some prefer not to use a file manager, it is still a good idea to provide a directory browser so the user has a choice.

 

If one chooses not to provide a directory browser, then the interface might act as follows:

 

  • When the user initiates Save, the program displays a modeless dialog with an input field, a Save button, and a draggable icon.  If the file does not exist on disk, the input field contains an example name.  If the file exists on the same machine, the input field contains the full path + name.  If the file exists on a different machine, the input field contains the full URL.

  • If the user drags the icon, use the XDS protocol and dismiss the dialog if successful.

  • If the input field contains a full path + name, the Save button should enabled.  If the user clicks it (or presses Return), save the file directly and dismiss the dialog if successful.

 

The source should report the error if it sends E in Step 2.  The target should report it if an error occurs in Step 3.

 

Other applications can use this protocol if they need the name of the data in addition to the data itself by simply retrieving the contents of the XdndDirectSave window property before requesting the actual data.

 

If a program expects a large amount of data (e.g. a video clip) then it could in principle pretend to be a file manager in order to obtain the data on disk instead of via the X Selection.  In this case, it must always set the property to zero length in Step 3 so the source doesn't think that the data has been saved.  Since this will only work if the source is on the same machine, however, it is usually better to use a Publish-Subscribe protocol where the target simply checks for modifications to a file written by the source.

 

<< Previous | Next >>

 

bottom of page