[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-awt-dev
Subject:    <AWT Dev> 4899516: Transferable has no DataFlavors when dragging from Gnome window to Swing
From:       damjan.jov () gmail ! com (Damjan Jovanovic)
Date:       2008-06-14 16:17:38
Message-ID: 9e89675b0806140917k53d37667j18bd3b3b2dd52f15 () mail ! gmail ! com
[Download RAW message or body]

Hi

Here's the second attempt.

On Wed, Jun 4, 2008 at 7:05 PM, Denis S. Fokin <Denis.Fokin at sun.com> 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.

Ok, I've added code to not publish a file list format to native when
Java is the drag source, and the Java URI list can't be losslessly
converted to a local file list. But, that means we have to call
Transferable.getTransferData() more than once during the same transfer
because it's now also called before the transfer has been accepted by
the drop target, maybe that should be documented.

It's not clear whether the opposite conversion (native URI list ->
Java file list) can be done safely; we'd have to request the data from
native at least once before the transfer has been accepted and I'm not
sure all platforms and applications support/like that. Currently
you'll get an empty file list.


> 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.

I've taken that paragraph out.

The documentation corrections Alla mailed me have also been put in.


> 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.

I've left it as private and inlined the contents of that method where
it's needed.

> Thank you,
>                  Denis.

Thank you
Damjan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 4899516-2.patch
Type: text/x-diff
Size: 21345 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20080614/1439e926/attachment.bin 

[prev in list] [next in list] [prev in thread] [next in thread]