<AWT Dev> 4899516: Transferable has no DataFlavors when dragging from Gnome window to Swing
damjan.jov at gmail.com
Wed Sep 26 01:20:38 PDT 2007
On 9/25/07, Denis S. Fokin <Denis.Fokin at sun.com> wrote:
> Hi Damjan,
> see my comments inline.
> Damjan Jovanovic wrote:
> > On 9/25/07, Denis S. Fokin <Denis.Fokin at sun.com> 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,
More information about the awt-dev