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

[Denis S. Fokin]

Hi Damjan,

I have some thoughts (sorry for the delay).

At first, I like your prototype. Thank you for your efforts.

So some ideas and notes are bellow.

1.
The first idea is we should not return an empty List<Files> list. The
better approach would be if we do not publish javaFileListFlavor data
flavor. In that case we have to analyze content of the URI list and
decide whether we can provide all URIs as files. If we cannot, user on
target must not receive javaFileListFlavor data flavor at all. Only
javaURIListFlavor.

2.
Some consideration about JavaDoc

******** DataFlavor.java ***********

+    /**
+     * To transfer a list of files and/or URIs to/from Java (and
+     * the underlying platform) a <code>DataFlavor</code> of this
+     * type/subtype and representation class of
+     * <code>java.util.List</code> is used. Each element of this
+     * list is required/guaranteed to be of type
+     * <code>java.net.URI</code>.
+     * <p>
+     * You should use this flavor instead of javaFileListFlavor,
+     * because some platforms provide only URI lists, not file
+     * lists. On these platforms, if and only if all URIs are
+     * files for the transfer in question, you can use/get
+     * javaFileListFlavor in addition to this flavor, for
+     * backward compatibility.

I think that there is no need to mention javaFileListFlavor here in case
if we are going provide javaURIListFlavor on Windows platform.

3.

**** DataTransferer.java ***************

-    private String getBestCharsetForTextFormat(Long lFormat,
+    protected String getBestCharsetForTextFormat(Long lFormat,

I do not think that changing access level is a good idea here. It is
needed only in single subclass so may be it would be better redesign
this approach.

Thank you,
                  Denis.

Damjan Jovanovic wrote:
> 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: 19392 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20080604/c73b2ffa/4899516.patch