Home » Modeling » EMF » Clarification on EditingDomainViewerDropAdapter.getDragSource(...) method
|
Re: Clarification on EditingDomainViewerDropAdapter.getDragSource(...) method [message #1639807 is a reply to message #1639400] |
Fri, 27 February 2015 20:47 |
Ed Merks Messages: 33218 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.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Re: Clarification on EditingDomainViewerDropAdapter.getDragSource(...) method [message #1639851 is a reply to message #1639807] |
Fri, 27 February 2015 21:18 |
Alex Kravets Messages: 561 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:47Alex,
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 |
Ed Merks Messages: 33218 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.
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
Re: Clarification on EditingDomainViewerDropAdapter.getDragSource(...) method [message #1645626 is a reply to message #1645566] |
Mon, 02 March 2015 16:04 |
Ed Merks Messages: 33218 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.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Tue Sep 24 21:44:11 GMT 2024
Powered by FUDForum. Page generated in 0.04589 seconds
|