This attempts to extract the drag source from the event early, i.e., before the drop method. This implementation tries to use a {@link org.eclipse.emf.edit.ui.dnd.LocalTransfer}. If the data is not yet available (e.g. on platforms other than win32), it just returns null.

Alex,

Yes, this is a limitation of the OS and is reflected in the behavior of
SWT itself. Only on Windows is the dragged object available during
dragging which allows better feedback for that OS. It doesn't mean the
method can't be used but rather that it's useless except on Windows.

BTW, for Oomph I did quite a bit of new work on drag and drag that I'd
like to move back to EMF when time permits. It uses the system
clipboard, is a cleaner design, and supports more conversion formats
(e.g., text and binary) such that it's possible to drag and drap (and
copy and paste) between processes...


On 27.02.2015 17:19, Alex Kravets wrote:
> In documentation for EditingDomainViewerDropAdapter.getDragSource(...)
> it says:
>
> Quote:
>> This attempts to extract the drag source from the event early, i.e.,
>> before the drop method. This implementation tries to use a {@link
>> org.eclipse.emf.edit.ui.dnd.LocalTransfer}. If the data is not yet
>> available (e.g. on platforms other than win32), it just returns null.
>
>
> So does this mean that this method is not to be used on operating
> systems other than win32? Why such limitation exists? Meaning why is
> this data not yet available on other platforms? In the tests that I did
> I see that nativeToJava conversion happens on drop() method in Linux.