Support default DragSource

[ewillink]

https://bugs.eclipse.org/bugs/show_bug.cgi?id=421054 complains that it is not possible to use the Plugin Dependencies as a DND link source; No org.eclipse.swt.dnd.DragSource is declared.

Suggest that a default DragSource is declared for all views so that the selection can be DNDed.

[merks]

I don't think this is feasible. Reading the Javadoc:

https://help.eclipse.org/latest/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fapi%2Forg%2Feclipse%2Fswt%2Fdnd%2FDragSource.html

it says that DragSource "defines the type of data that is available for dragging and the set of operations that can be performed on that data" So which types and operations should be supported by default? If even if that weren't already a minor problem, it also says "You may have several DragSources in an application but you can only have one DragSource per Control." so if a DragSource that supports some predetermined types and supports some predetermined set of operations, downstream it would no longer be possible to create a DragSource for the viewer's control, so that seems like a major problem.

I don't see a way around that limitation. Do you?

Perhaps the path of least resistance is to contribute simple minimal drag sources to the PDE views for which you want that support and don't already have it:

https://github.com/eclipse-pde/eclipse.pde?tab=readme-ov-file#how-to-contribute

[Bananeweizen]

My personal feeling is that DnD is used rather seldomly by end users in comparison to other actions like context menus, because it's hard to guess beforehand what will or will not happen when dropping something, and because typically there is an explicit UI control for doing the same action anyway (like a "browse" or "select" button). Given that assumption and the complexity around correctly implementing DnD I would tend to spend resources more on other UI improvements.

[ewillink]

This suggestion arose from debugging the incompatibility between the JDT's Package Explorer and Sirius' Model Explorer and responding to a vintage OCL bug observing that DND from the Plugin Dependencies was not supported. For these, it appeared that the View was the potential Drag Source declarer, so that an abstract View could provide a default that supports 'selections'. Views that know better should obviously override / extend.

I have not studied all the processing, but it seems that the DragSource defines possible source types, and the DragTarget possible target types. The actual transfer occurs after filtering the selection through the permutation of all possible source and target types. Transfer occurs for the first permutation that each of selection, source and target support. So a default DragSource should probably be exactly what the Package Explorer declares:

transferAgents org.eclipse.swt.dnd.Transfer[3] (id=1028)
[0] org.eclipse.jface.util.LocalSelectionTransfer (id=1042)
[1] org.eclipse.ui.part.ResourceTransfer (id=1043)
[2] org.eclipse.swt.dnd.FileTransfer (id=1044)

The DragSource is typically declared shortly after creation,. so a derived view should overeride a default in standard fashion. A nested control may occlude the outer view using standard widget precedence.

Selection is an Eclipse-wide facility, DND using the selection should IMHO also be an Eclipse-wide facility, not just something that only works for non-default views.

[ewillink]

@Bananeweizen Yes arbitrary DND is little used and, when considering significant object trees, difficult to predict / implement. Perhaps a chicken and egg problem.

My use case is just identity. Rather than discovering the correct spelling then typing "platform:/resource/org.eclipse.qvtd.pivot.qvtbase/model/QVTbase.ecore#T-qvtbase-TypedModel", it is so much easier to select the object then DND its 'identity' into a Text control. Much easier than navigating through a Browse Workspace... dialog to rediscover what was already known.

If I am right in thinking that a single abstract view method is possible then the fix may be a barely 10 line new method.

[merks]

Here's how it actually works:

Application developers using a viewer must add the drag support explicitly via addDragSupport. When they do that, they must decide the operations, the transfer types, and add a listener for processing the actions. That listener must do things, e.g., do a remove if a move operation is applied, of course depending on what operations are actually supported for that drag source. As such I see no way to work in an "implicit default" behavior in a way that will not interfere with the current design which requires explicit opt-in. Perhaps someone more clever than me will see a way.

So, if you don't wish to contribute a concrete solution specifically for PDE, then you should look closely at how the framework works currently and make a concrete, clever proposal. No one else is likely to do this on your behalf.

[ewillink]

Your use of 'application' developers ignores the potential independence of source and target applications.

For org.eclipse.ocl.xtext.completeocl.ui.commands.LoadCompleteOCLResourceHandler, I defined a DropTarget and transfers and operations realised by the 'custom' URIDropTargetListener.

int operations = /*DND.DROP_MOVE |*/ DND.DROP_COPY | DND.DROP_LINK; target = new DropTarget(uriField, operations); target.setTransfer(new Transfer[] {ResourceTransfer.getInstance(), FileTransfer.getInstance()}); target.addDropListener(new URIDropTargetListener());

(uriField is a Text control). That is it. The code is blind to the source.

Similarly the JDT Package Explorer developers, who surely know nothing about OCL applications, defined and initialized a generic drag source with File and Resource transfers. The Package Explorer is therefore a suitable drag source for any application defining a drop target that requires Files or Resources.

When source and target transfers align and non-dummy methods are invoked, a transfer may proceed. It seems like a really good flexible design. The JDT Package Explorer functionality just needs promoting to an abstract view.

I'm not sure that there is a compatibility problem. Currently no source support means nothing happens. If a source is defined then that will still be used. e.g. an attempt to DND from a file entry in the Git History currently gives a nothing-doing cursor. With a default drag source the file entry or content could be used by DND without changing any Git code.

[merks]

The potential merit is clear. Once you have a concrete solution to propose via a PR that can be peer reviewed, we can make further progress.