Hi Damjan,
Please find some comments on javadoc.
Note: the <code> tag is considered outdated, use the [EMAIL PROTECTED] notation
instead.
1.
+ *
+ * You should generally use javaURIListFlavor instead of this.
*/
I'd suggest:
+ *
+ * Use the [EMAIL PROTECTED] 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 [EMAIL PROTECTED] DataFlavor} of this type (subtype) and
representation
+ * class of the [EMAIL PROTECTED] 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 [EMAIL PROTECTED] java.net.URI} type.
+ * <p>
+ * Use this flavor instead of [EMAIL PROTECTED] javaFileListFlavor},
+ * because some platforms support only URI lists, not file
+ * lists. On these platforms you may use [EMAIL PROTECTED]
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 [EMAIL PROTECTED] true} if the specified [EMAIL PROTECTED]
DataFlavor} represents
+ * a list of URI objects.
+ * @return [EMAIL PROTECTED] true} if the specified [EMAIL PROTECTED]
DataFlavor} represents
+ * a [EMAIL PROTECTED] List} of [EMAIL PROTECTED] File} objects
+ */
4.
/**
+ * Determines whether the DataFlavor corresponding to the specified long
+ * format is DataFlavor.javaURIListFlavor.
+ */
Minor corrections:
/**
+ * Determines whether the [EMAIL PROTECTED] DataFlavor} corresponding to
the specified long
+ * format is [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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
begin:vcard
fn:Alla Redko
n:Redko;Alla
email;internet:[EMAIL PROTECTED]
title:Technical writer
tel;work:x33361
version:2.1
end:vcard
