On 9/25/07, Denis S. Fokin <[EMAIL PROTECTED]> wrote: > Hi Damjan, > > see my comments inline. > > Damjan Jovanovic wrote: > > On 9/25/07, Denis S. Fokin <[EMAIL PROTECTED]> wrote: > >> Hi Damjan, > >> > >> Currently, in the AWT implementation there is no data flavor like > >> DataFlavor.javaFileListFlavor for uri-list mime-type. > >> > >> What is more a change request exists related to the issue. > >> > >> CR "4899516 Transferable has no DataFlavors when dragging from Gnome > >> window to Swing" > >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4899516 > >> > >> You can find in the workaround section how to create a custom > >> Transferable to transfer the uri-list mime-type data. > >> > >> So I cannot agree that AWT "has zero support for the X file drag > >> specification" =) > >> > >> But the question about a better support is disputable. > >> > >> There are number of ways how to solve the task to implement DnD between > >> java application and GNOME nautilus. > >> > >> The first one is to implement some kind of analysis in AWT code. In that > >> case we could introduce a new default DataFlavor like > >> DataFlavor.javaFileListFlavor. > >> return from Transferable.getTransferData() a list of URIs. Note, that we > >> cannot be sure, that provided by Gnome data contains files, so we cannot > >> use DataFlavor.javaFileListFlavor. > > > > It's not Gnome-specific, it's XDND specific. Files are a subset of > > URIs, and DataFlavor.javaFileListFlavor is a (possibly empty) subset > > of a URI list. > > I mentioned GNOME as a known supporter of XDND protocol =) > > As far as DataFlavor.javaFileListFlavor is a (possibly empty) subset, I am > not sure that we can map text/uri-list on DataFlavor.javaFileListFlavor. > > > > >> The second way is to implement some TransferHandler in Swing library. > > > > You've already done something like that for other file drop protocols. > So did you mean some improvements in the same direction? > > > >> The third way is to give programmer a possibility to decide how to > >> handle the uri-list. > >> > >> I do not see a problem with the third variant. > > > > I do. You have to write platform-specific code, which defeats the > > purpose of using Java, and you have to modify every existing program > > that already uses drag-and-drop to support it. > > I do no think that it should be platform specific code. It is just a support > for "text/uri-list" mime-type transfer. > > > > >> Could you describe in more details in what way do you see better support > >> of X file drag specification? > > > > There is no reliable, portable way to tell a drop is a file drop. > > DataFlavor.isFlavorJavaFileListType() returns false for all flavors on > > an XDND file drop. It should return true for at least one. > > I am not sure that it should, as far as "text/uri-list" type is not file list > type (it is a superset). > But if we would have a method DataFlavor.isFlavorUriListType() it possibly > should returns true for DataFlavor.javaFileListFlavor. > > > > > When you find a file drop flavor, you should be able to treat it the > > same on all platforms. No "if it's a text/uri-list do this, otherwise > > do that". > > I still think that text/uri-list should have its own DataFlavor.
> > > > The X file drag specification > > (http://www.newplanetsoftware.com/xdnd/dragging_files.html) is clear > > that "Simple programs can reject files that are not available > > locally...". So there is nothing wrong with dropping non-file URIs, > > and converting a URI list to a file list. It is also fully compatible > > with software already written. > > > > At the same time, URIs are supersets of files and advanced programs > > might want to use URI lists instead of file lists, or Java could even > > provide an array of InputStreams that can read from the dropped > > files/URIs. That could be opt-in functionality in future versions of > > Java. > > Do you mean that it would be useful to analyze whether file names are > presented in the list and if file names are presented provide them when user > requests DataFlavor.javaFileListFlavor? In case if there are no file names > (e.g it could be a list of URLs) we should provide empty list by request. Am > I correct? > Since no other operating system would ever have an empty file list, maybe the following is better: always provide a uriListFlavor, but if at least one URI is a file, provide a javaFileListFlavor as well. Out of interest, SWT already converts text/uri-list to a local file list ignoring non-file URIs. > Thank you, > Denis. Thank you Damjan
