[platform-ui-dev] Delegatring drag & drop, bug 10146

[Knut Radloff <knut_radloff@xxxxxxxxxx>]

http://bugs.eclipse.org/bugs/show_bug.cgi?id=10146

The following is quoted from the bug report. This should be of interest to 
anyone implementing drag and drop support in their Eclipse plugins. 
Feedback is encouraged, especially from anyone who copied the JDT or GEF 
DelegatingDragAdaper/DelegatingDropAdapter code.
Again, please note that the new classes are experimental in nature and may 
be removed in the future.

Knut

"I released an experimental version of the delegating drag and drop support 
to 
org.eclipse.jface. 
The files are:
org.eclipse.jface.util.DelegatingDragAdapter
org.eclipse.jface.util.DelegatingDropAdapter
org.eclipse.jface.util.TransferDragSourceListener
org.eclipse.jface.util.TransferDropTargetListener

The two concepts/benefits of the delegating drag and drop are:
1) Allowing a 1:1 mapping between transfer type and listener.
  The listener implementation depends on the transfer type. This is 
certainly 
true for dragSetData and drop. In the Resource Navigator use case the 
dragEnter, dragFinished and dragStart implementations vary depending on 
the 
transfer type. The listener code will be greatly simplified if it can be 
separated by transfer type.
The current SWT listener in DragSource/DropTarget does not allow for a 
clean 
separation by transfer type.

2) Controlling enablement of listeners.
  Drag listener enablement often depends on selection state. Based on the 
selection some or all transfer types may not be valid. In the GEF use case 

finer control over drop enablement is needed as well. Drop enablement may 
change based in the drag operation and location.

The question is if SWT can provide more fine grained drag and drop 
listener 
support. 
Scenario 1) could be supported by adding API that allows setting a 
listener for 
a specific transfer type. The code I released adds a method #getTransfer() 
to 
the drag/drop listener interface for this purpose. There are other 
options.
Scenario 2) could be supported by adding a doit field to the 
dropTargetEvent. 
The current code uses the dragStart doit field of the DragSourceEvent and 
adds 
a method #isEnabled to the drop listener interface to determine enablement 
of a 
particular listener.

Interested parties are encouraged to provide further input they may have, 
including corrections and additions to the two scenarios I provide and the 

changes to SWT that I suggest. Please verify that the SWT changes I 
suugest and 
the preliminary code I released would be sufficient for your use cases."