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

[Alla Redko]

Hi Damjan,

Please find some comments on javadoc.
Note: the <code> tag is considered outdated, use the {@code} notation 
instead.

1.

+     *
+     * You should generally use javaURIListFlavor instead of this.
      */

I'd suggest:

+     *
+     * Use the {@code javaURIListFlavor} class instead.
      */

2. 

+    /**
+     * 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.
+     *
+     * @since 1.7
+     */ 

I'd rephrase:

+    /**
+     * A {@code DataFlavor} of this type (subtype) and representation
+     * class of the {@code java.util.List} class are used to transfer a list of files
+     * or URIs to Java and the underlying platform. Each element of this
+     * list is required to be of the {@code java.net.URI} type.
+     * <p>
+     * Use this flavor instead of {@code javaFileListFlavor},
+     * because some platforms support only URI lists, not file
+     * lists. On these platforms you may use {@code javaFileListFlavor} as well
+     * to provide backward compatibility.
+     *
+     * @since 1.7
+     */ 

3. 

+   /**
+    * Returns true if the <code>DataFlavor</code> specified represents
+    * a list of URI objects.
+    * @return true is the <code>DataFlavor</code> specified represents
+    *   a List of File objects
+    */

My corrections:

+   /**
+    * Returns {@code true} if the specified {@code DataFlavor} represents
+    * a list of URI objects.
+    * @return {@code true} if the specified {@code DataFlavor} represents
+    *   a {@code List} of {@code File} objects
+    */

4. 

     /**
+     * Determines whether the DataFlavor corresponding to the specified long
+     * format is DataFlavor.javaURIListFlavor.
+     */

Minor corrections:

     /**
+     * Determines whether the {@code DataFlavor} corresponding to the specified long
+     * format is {@code DataFlavor.javaURIListFlavor}.
+     */

5.

+    /**
+     * Translate a transferable to a URI list. The default implementation
+     * provides a text/uri-list MIME type in the target encoding.
+     */

Minor corrections:

+    /**
+     * Translates a transferable object to a URI list. The default implementation
+     * provides a text/uri-list MIME type in the target encoding.
+     */

6. 


+    /**
+     * Decode URIs from either a byte array or a stream.
+     */

A minor correction:

+    /**
+     * Decodes URIs from either a byte array or a stream.
+     */

Best regards, 
Alla



Denis S. Fokin wrote:
> 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
>>   
>>     
>
>   

-- 
Alla Redko
Technical Writer
Sun Microsystems, Inc.
Sun Internal: x33361

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20080605/4405848a/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Alla_Redko.vcf
Type: text/x-vcard
Size: 135 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20080605/4405848a/Alla_Redko.vcf