Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Clarification on EditingDomainViewerDropAdapter.getDragSource(...) method
Clarification on EditingDomainViewerDropAdapter.getDragSource(...) method [message #1639400] Fri, 27 February 2015 16:19 Go to next message
Alex Kravets is currently offline Alex KravetsFriend
Messages: 543
Registered: November 2009
Senior Member
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.
Re: Clarification on EditingDomainViewerDropAdapter.getDragSource(...) method [message #1639807 is a reply to message #1639400] Fri, 27 February 2015 20:47 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30465
Registered: July 2009
Senior Member
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.
Re: Clarification on EditingDomainViewerDropAdapter.getDragSource(...) method [message #1639851 is a reply to message #1639807] Fri, 27 February 2015 21:18 Go to previous messageGo to next message
Alex Kravets is currently offline Alex KravetsFriend
Messages: 543
Registered: November 2009
Senior Member
Thanks, Ed.

Is there a workaround for this? Looking at the code in EditingDomainViewerDropAdapter it looks like it relies on getting sources for the drag event pretty early.

Ed Merks wrote on Fri, 27 February 2015 15:47
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.

[Updated on: Fri, 27 February 2015 21:19]

Report message to a moderator

Re: Clarification on EditingDomainViewerDropAdapter.getDragSource(...) method [message #1640786 is a reply to message #1639851] Sat, 28 February 2015 08:17 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30465
Registered: July 2009
Senior Member
Alex,

It's an OS limitation. If the data is available there is better
feedback during the dragging. If there were a workaround, SWT would
have provided an API that behaved uniformly across each OS, but it doesn't.


On 27.02.2015 22:18, Alex Kravets wrote:
> Thanks, Ed.
>
> Is there a workaround for this? Looking at the code in
> EditingDomainViewerDropAdapter it looks like it's relies on getting
> sources for the drag event pretty early.
>
> Ed Merks wrote on Fri, 27 February 2015 15:47
>> 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.
>
>
Re: Clarification on EditingDomainViewerDropAdapter.getDragSource(...) method [message #1645566 is a reply to message #1640786] Mon, 02 March 2015 15:27 Go to previous messageGo to next message
Alex Kravets is currently offline Alex KravetsFriend
Messages: 543
Registered: November 2009
Senior Member
Ed,

From debugging that I did I see that transfer data is available in drop() method on Linux, not early in getDragSource() method as on Windows. Can't EditingDomainViewerDropAdapter be re-factored to use drop() method to get sources and build command since this is where data is available on Linux?

Unfortunately it's hard to try this because of a bug on Linux where during debugging DnD Eclipse freezes.
Re: Clarification on EditingDomainViewerDropAdapter.getDragSource(...) method [message #1645626 is a reply to message #1645566] Mon, 02 March 2015 16:04 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 30465
Registered: July 2009
Senior Member
Alex,

Comments below.

On 02/03/2015 4:27 PM, Alex Kravets wrote:
> Ed,
>
> From debugging that I did I see that transfer data is available in
> drop() method on Linux, not early in getDragSource() method as on Windows.
Yes.
> Can't EditingDomainViewerDropAdapter be re-factored to use drop()
> method to get sources and build command since this is where data is
> available on Linux?
No, because all this depends on the underlying SWT implementation which
depends on the underlying OS implementation and only on Windows is this
information available earlier in the OS events.
> Unfortunately it's hard to try this because of a bug on Linux where
> during debugging DnD Eclipse freezes.
Yes, debugging drag and drop is a nightmare.
Previous Topic:Is "Feature id" = Properties tab "ID"
Next Topic:EcoreUtil.EqualityHelper and 'ordered' feature
Goto Forum:
  


Current Time: Mon Sep 23 09:56:14 GMT 2019

Powered by FUDForum. Page generated in 0.04430 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top