Community
Participate
Working Groups
We have a problem in the Team use of the Common Navigator is that each repository provider may define one or more viewers. It is not practical for each of the viewer definitions to define the complete set of drag assistants, especially considering that each model may have their own elements that can be dragged. It would simplify things if we could just programmatically bind drag assistants to a viewer. Then we could bind he resource drag assistant to all Team viewers for free. Currently, each provider with a viewer must add a dependency to the org.eclipse.ui.navigator.resources plugin and then add the dragAssistant binding to each viewer.
This should be easy to support. To handle this, the call would looks something like: INavigatorContentService.getDnDService().bindDragAssistant(CommonDropAdapterAssistant) Would the same capability be required for CommonDropAdapterAssistants? This would be trickier since the drop assistants are filtered using core expressions; and I'm not aware of a clean way to handle the creation of these expressions programmatically. Each drop assistant is currently associated with a particular navigatorContent extension; which means potentially the drop assistant could/would have to be programmatically bound to a particular extension. At first glance, I'm not sure this would be very clean ...
Aren't the drop assistants associated with a navigatorContent extension already? If so, that is good enough since any model provider can define their own drop assistants. The problem with drag assistants is that they are conceptually linked to navigator content but must be associated with a viewer because that is what JFace/SWT requires. If I had the capability to register drag assistants programmatically, I would need to register the assistants for all models in case they ever showed content in the view. This is fine if the number is small but doesn't really scale. However, if the API is straightforward for you to add and you are comfortable putting it into 3.2, I can use it internally in 3.2 to get the resource transfer and then woryy about how to surface the API to Team clients in 3.3. This would free clients from putting the assistant in their viewers which would give me more flexibility as to how to surface the API in 3.3.
Drop assistants are associated with extensions, and they can define their own. I don't anticipate there ever being a large number of drag assistants; these are really a mechanism to add new Transfer Types.
Created attachment 35282 [details] Adds INavigatorDnDService.bindDragAssistant()
Michael, it looks like this patch incorporates a bunch of other work than just the request here. This makes it hard for me to review the API change for this request. Would it be possible to provide a simpler patch?
Created attachment 35316 [details] The real patch
I inadvertantly attached the patch for DND_126658 instead of this change.
Looks good to me. McQ, you can +1 the API change.
agreed. +1. ok to proceed.
Michael, this API change has gotten approval. It would be best if it made it into M6.
Released patch.
