Community
Participate
Working Groups
Dragging EditorInputData into the editor area using EditorInputTransfer is a general functionality that is not specific to an IDE. However part of this functionality is now implemented inside org.eclipse.ui.internal.ide.EditorAreaDropAdapter which makes it impossible to use it in an RCP application without either having a dependency on org.eclipse.ui.ide or copying the implementation. This class should be refactored so that the functionality concerning EditorInputTransfer is moved into a base class available outside org.eclipse.ui.ide plugin (probably in org.eclipse.ui.workbench plugin?).
EditorAreaDropAdapter is IDE-specific, having knowledge about resource-specific types like IResource and IMarker, not just the general IEditorInput. RCP apps can configure their own editor area drop support using IWorkbenchWindowConfigurer.addEditorAreaTransfer and configureEditorAreaDropListener. To see how this is done in the IDE, see IDEWorkbenchWindowAdvisor.preWindowOpen(). Note that the general EditorInputTransfer is API in the generic workbench. I agree that the factoring here could be improved though. In particular, it would be good to be able to register different drop handlers for the different transfer types. Also, there's no real reason for these to be "privileged" API in the advisors. It should be possible to contribute editor area drop handlers via a regular extension point.
Yes, I've seen IDEWorkbenchWindowAdvisor.preWindowOpen() and I know that EditorAreaDropAdapter handles not only EditorInputTransfer and therefore has dependency on IDE classes. I thought the first step to improve that would be to make this class extend a new class containing only EditorInputTransfer related functionality and located outside org.eclipse.ui.ide that could be reused in RCP. Of course registering drop handlers via extension point would be great too :)
I'd prefer to have a more extensible solution than just enabling subclassing.
Reassigning bugs in component areas that are changing ownership.
Any progress on this enhancement? I think I was burned by this in bug 287486.
From bug 287486 comment #5: > (In reply to comment #4) > > right, but StyledTextDropTargetEffect#dropAccept sets currentOffset to -1. > > do you know why dropAccept is not being called ? > > Yes, the problem was at our end. <sound of hand smacking head/> > > We implement our own WorkbenchWindowAdvisor which did not setup drag and drop > support for the editor area while IDEWorkbenchWindowAdvisor.preWindowOpen() > does. > > During the dragOver event call, the EditorSiteDragAndDropServiceImpl's internal > MergedDropTarget.getAppropriateListener(DropTargetEvent, boolean) is called and > it does not have a secondaryListener to handle the dragOver. A null is returned > and all hell breaks loose. > > Simply adding the following to our own WorkbenchWindowAdvisor implementation > solved the problem. > > @Override > public void preWindowOpen() { > IWorkbenchWindowConfigurer configurer = getWindowConfigurer(); > .... > configurer.configureEditorAreaDropListener(new EditorAreaDropAdapter( > configurer.getWindow())); > } > > Looks like this is related to #99905. > > A quick search shows no documentation stating the above code must be called. > The built in RCP examples does not include it. > > Thank you for your time. >
Eric, this looks like EditorSiteDragAndDropServiceImpl is making an assumption that does not hold for RCP apps - would you be able to investigate?
Prakash is now responsible for watching bugs in the [RCP] component area.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
