<AWT Dev> 4899516: Transferable has no DataFlavors when dragging from Gnome window to Swing

Damjan Jovanovic damjan.jov at gmail.com
Wed May 14 06:34:48 PDT 2008


On Mon, Oct 1, 2007 at 7:53 PM, Denis S. Fokin <Denis.Fokin at sun.com> wrote:
> Hi Damjan,
>
> > Ok I'm sorry for arguing so much. Less talk more code :-).
>  >
>  > This weekend I started writing code for URIListFlavor, but I quickly
>  > realized another problem. If you deprecate javaFileListFlavor and use
>  > URIListFlavor, the problem still exists in the opposite direction:
>  > when Java is the drag source and a native application the drop target,
>  > on non-XDnD implementations you still have to do lossy conversion from
>  > URIs to Files and somehow disregard non-local-file URIs, and possibly
>  > provide the native application with an empty file list.
>  >
>  > Any ideas?
>  >
>  >
>  Currently, AWT supports OLE Drag & Drop protocol on Windows platform,
>  XDnD and Motif Drag & Drop protocols on UNIX-like platforms.
>
>  In case if some application asks our java source about available
>  formats, we will provide javaFileListFlavor only if among our data files
>  are presented.
>
>  On the basis of a value returned by uri.getScheme() method we could
>  understand whether we should provide javaFileListFlavor for native
>  application.
>
>  In this case we will not publish native flavors for file list (e.g.
>  HDROP on windows).
>
>  I suppose, the same scenario should works for java intra-jvm transfer.
>
>  To summarize, as far as we have all information on drag source we can
>  publish only data flavors which we really have.
>
>  But I could miss out something, so give me know where the problems arise.
>
>  Thank you,
>     Denis.
>

Hi again

I've made a patch that works for me (attached). It adds a
java.awt.datatransfer.DataFlavor.javaURIListFlavor of MIME type
application/x-java-uri-list;class=java.util.List, and does full
bidirectional conversion between file lists and URI lists. That is,
file lists are promoted to URI lists, and URI lists are lossily
converted to file lists.

If you drag a file list from native into Java, the application sees
both a URI list and a file list. If you drag in a URI list it sees a
URI list, and if all URIs are files also a non-empty file list,
otherwise just an empty file list. If a Java drag source provides a
file list to native then native sees both a URI list (where
implemented on native) and a file list, and where Java provides a URI
list native sees the URI list (where implemented) and the subset of
files taken from those URIs that are local files (javaFileListFlavor
already uses similar logic: it just ignores non-String non-File
entries).

What happens when native doesn't support URI lists and a Java drag
source provides it? Currently if native doesn't support a URI list
format, you won't be able to do inter-JVM and Java->native URI list
transfers, only the local files in those URIs will go through and be
seen as a file list by the other side. Out of Windows, X11, and Motif,
in my patch currently only X11 supports them :-(. I haven't been able
to find proper URI list support in Windows, most of the fancy shell
clipboard types that can transfer URLs and such, seem to only transfer
1 item instead of a list.

Otherwise I've tested dragging files between Java and Gnome's
Nautilus, in both directions. It works well :-).

Thoughts? Suggestions?

Bye
Damjan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 4899516.patch
Type: text/x-diff
Size: 19391 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20080514/c9dc7199/4899516.patch 


More information about the awt-dev mailing list