Hi Is anybody working on this bug (http://bugs.sun.com/view_bug.do?bug_id=4808793)?
If not I'd like to have a go at it. My idea is described below. java.awt.datatransfer.DataFlavor.javaFileListFlavor has drop target pull semantics, with the drop target being responsible for the operation on the files. It needs the files to already exist. It's essentially a "take these files and use them" action. For example, if you drag files into a Java SVN client, the SVN client could check them in. These semantics work when the drop target is not the local filesystem. But these semantics are exactly the opposite of what's needed when the files in the drag source are not actual files from the local filesystem - for example they are files in an FTP server or even virtual files that don't exist yet. For this we need drag source push semantics, with the drop target either telling the drag source where to save the files, or using some sort of protocol to move the file contents from the drag source to wherever they are to be saved or used. Windows, X11 and MacOS all support this latter option, and while it is a less commonly used file drag scenario, some important applications require it (eg. Microsoft Outlook) and others support it among other possible formats (eg. Windows Explorer, GIMP, File Roller). The bug has been open since early 2003 and has 60 votes; the drag from Microsoft Outlook to Java bug (http://bugs.sun.com/view_bug.do?bug_id=6242241) which relies on this bug has another 20 votes. Windows has the CFSTR_FILEDESCRIPTOR/CFSTR_FILECONTENTS formats for this. Basically files are presented using their contents, in the form of IStream, IStorage or HGLOBAL, with additional data describing the file name and properties (http://msdn.microsoft.com/en-us/library/bb776902(VS.85).aspx). OS X has "promise data flavors" (http://developer.apple.com/documentation/Carbon/Reference/Pasteboard_Reference/Reference/reference.html). The drag source supplies a promise instead of data, and a callback that's invoked to supply the data. When the callback is called, it can get a URL where the files should be saved. X11 has the X direct save protocol (http://www.freedesktop.org/wiki/Specifications/XDS), which seems to be a mixture of the Windows and OS X ways. The emphasis in the protocol is on saving a file, rather than transferring a list of files. First the drop target gives the drag source a URL where to save the file(s), just like OS X would. If the drag source cannot access that URL or doesn't have permission, it reports this to the drop target, and the drop target then falls back to requesting the file contents as application/octet-stream - similar to the Windows way, but it only works for one file. Obviously there are big differences on these platforms that AWT has to unify. Here is a proposal of how. Drop target We add a new DataFlavor, called FileDropReferralFlavor. When the drop target asks for this flavor, it gets back an object called FileDropReferral, and must call a "public void setFileDropLocation(URL location)" method to tell the drag source where it should save the files. The file transfer proceeds asynchronously, and potentially within the JVM (ie. the application shouldn't exit if it has outstanding transfers). After the transfer is complete, some event to that effect is sent to the drop application's EDT, maybe to a listener registered with the FileDropReferral. Drag source The drag source uses a different DataFlavor to provide its files as streams, say AsyncFileStreamsFlavor. After the drop it provides an enumeration that can be used to lazy open InputStream objects, and some kind of header at least naming each stream. Implementation: On all platforms, when Java is the drag source it spawns a separate thread where possible, and writes the streams into the drop target or URL. When Java is the drop target, on Windows, it spawns a separate thread where possible and reads in the streams and saves them to the target URL that the drop target set, while on X11 and MacOS it just provides the target URL to the drag source and lets the drag source do the saving. These interfaces are unintuitive, asymmetric and ugly. But then again desktops in different operating systems have given file transfers little real thought so there isn't much better we can do now, and it's still vastly uglier to do these in native code (using COM or low-level X11 - yuck!) than in Java. Also this is an advanced DataFlavor, which should be used by a minority of applications, and only in special cases where javaFileListFlavor doesn't fit. Finally, GTK+ still doesn't even have an API for this, SWT is struggling and only works on Windows, and even Microsoft's .NET doesn't support this (http://www.pcreview.co.uk/forums/thread-1854594.php) so this is a real opportunity for Java+AWT/Swing to be a shining example and lead the way. Any thoughts before I start hacking? Regards Damjan
