Hi Damjan,
personally, I like the idea to implement a set of predefined DataFlavours. In
particular to provide predefined DataFlavor represented a List of URI is very
good idea.
But I do not like idea to modify the handling of DataFlavor.javaFileListFlavor
flavor.
There are two issues bothering me.
1. list of Files could be empty.
2. the question how to convert URI in File is open. How we should interpret
"ftp:///"; protocol in this case? Would be our new interpretation compatible
with existing applications and so on.
Another solution which I see is to keep the current handling of
DataFlavor.javaFileListFlavor flavor unchangeable. But mark it as deprecated.
Like it is done whith the DataFlavor.plainTextFlavor. And suggest to use the
new URI list data flavor instead of the deprecated one.
The new data flavor will contain list of URI and will cover all protocols. On
Windows all returned URI will be URI of files.
In that case, another question that should be answered is if we will convert
native uri-list mime type at the same time in DataFlavor.javaFileListFlavor and
a list of URI, should we do the same conversation when transfer is local or
intra-jvm? In case of transfer between two java applications, user could
provide only URI list flavor. Should we provide DataFlavor.javaFileListFlavor
to target as well in that case?
So the second solution has it's own issues but looks much more appropriate for
me.
Thank you,
Denis.
Damjan Jovanovic wrote:
On 9/25/07, Denis S. Fokin <[EMAIL PROTECTED]> wrote:
Hi Damjan,
see my comments inline.
Damjan Jovanovic wrote:
On 9/25/07, Denis S. Fokin <[EMAIL PROTECTED]> 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,
Denis.
Thank you
Damjan
