Community
Participate
Working Groups
I have been having a discussion on the JDT newsgroup about the following use case: A user selects a widget in my View, drags, and drops it into the Java editor. The drop processor for this operation wants to add some code to the current compilation unit. Furthermore, current behavior wants to be preserved: for example, if the user drags a file from the pkg explorer into the editor, the editor opens the file. I have written some experimental code (attached) to try to accomplish this. I have succeeded in getting a drop event when I drop something onto the editor window. However, current behavior is not preserved: I don't know how to pass an event I'm not interested in along to the current infrastructure, to be handled as though my View was not in the picture (i.e. had not placed a DropListener on the Editor at all). Dani Megert from the JDT suggested that if I obtained the Control from the Editor and constructed a new DropTarget with it (see below), that if I set event.detail = DND.DROP_NONE in DropTargetListener#drop(), it would pass the event on to the next possible listener. However it does not seem to. If I set detail = DROP_NONE I do get different behavior than doing nothing: A progress dialog briefly flashes on the screen (progress for what I don't know), but nothing else happens. After digging around, I wrote some very hacky code to get hold of the o.e.ui.internal.ide.EditorAreaDropAdapter, to try to pass the event on to it directly, but 1) I shouldn't do that, and 2) it doesn't work either. Is there a way to do this? Or will it involve a new API? This is a very important use case for BEA. In the attached plugin project, the source file in question is dragon.views.SampleView.java; the methods are hookDragonDrop() and MyDropListener#drop().
Created attachment 33908 [details] zip of plugin project with repro
VI to investigate.
Why are you trying to modify the drop target? You view should create a drag source that provides TextTransfer and/or FileTransfer and/or resource-transfer-format and/or local-selection-transfer-format or whatever data represents what you are providing. Then the drop target which is the editor will decide what to do with the data when it is dropped (insert text etc). Your view should not be telling the editor what to with the data when it is dropped. Really the DropTarget should have been created by the editor on the StyledText widget in the first place and then you would not be able to call new DropTarget(ctrl, DND.DROP_COPY) and get in the way (you can only have one DropTarget per Control). I am not sure why Eclipse is relying on the fact that a drop target for the parent (in this case EditorSashContainer) applies to the children unless the children define their own drop target. This is dangerous and I am not even sure that it is supported across all platforms. It is not a very good design because only the editor can really know what kind of data can be dropped on it. Nick, MvM, can you comment on why the design creates the DropTarget for the EditorSashContainer?
The IDE's editor area handles drops for editor inputs, resources and markers in order to allow files to be opened via DnD. E.g. drag a file from the Navigator or Package Explorer over the editor area. (this is set up in IDEWorkbenchAdvisor.preWindowOpen()). If the editor itself can handle the drop, then it should override this behaviour. I think that's what Gary is trying to accomplish. Veronika, can you advise on whether this is possible, and if so how it should be handled?
It is not possible to have a DropTarget for a child that defers to a DropTarget in the parent. The child DropTarget completely overrides the parent one. There is no way to interact between the two. This is the way the native behaviour works. The UI can perhaps add to its framework to allow editors to add to the transfer types allowed by the drop target. Note that if you have a DropTarget for EditorSashContainer and a DropTarget for the JavaEditor StyledText widget, the parts of the EditorSashContainer that are not covered by the StyledText widget will still accept the files.
Is this true even if the inner control cannot accept any available transfers, but the outer one can? I would expect it to keep looking up for the first target that can accept any of the transfers. Without such support, we would require strong coupling between the editor and the workbench in order to coordinate DnD.
OK let me clarify the use case: The user doesn't drag something that represents specific text to some specific point in the file. He grabs, e.g. a "control" widget from a pallette, drags it into a Java pageflow file, and drops it anywhere. The position of the drop within the target is, in this case, not germane. (See http://beehive.apache.org for a further description of pageflows and controls if you're curious -- it shouldn't be necessary to understand the example though, I don't think.) He expects the gesture to mean "add a reference to this control to this source file". This involves sprinkling some ASTRewrites though the file: a definition of the reference variable, some JSR 175 annotations (sometimes an annotation my be added, other times an existing one (or ones) may be modifed)... It's a complex operation that the Editor would not have any way of understanding by itself. So, for operations that the Editor does have understanding of (like dragging a file icon in from the pkg explorer, or some text from another app (which would be nice but that's another story :), the editor should get the drop event, and do with it what it knows how to do. But there should be a way of pre-empting a drop from a View which actually wants to do special processing when one of its widgets is dropped on the Editor. In the latter case the editor doesn't actually want to see the drop event -- it should only see source updates that implement the semantics of the gesture, and be unaware of the gesture itself. You have the following choices:
Sorry, "you have the following choices" above got stuck on when I copied text after Bugzilla detected an update conflict. Anyway further response to above comments: Right now there is a separate drop target on the editor sash, and the editor window itself. In my code I happened to hook the editor window, but I'd actually like to hook the outermost control that looks to the user like the editor drop target. Is this the sash? Currently when the pointer hovers over the sash, I get the original behavior, and when it hovers over the editor window, I get my behavior. This will be a confusing user experience...
Regarding Comment #6 - yes this is true. There is no delegation between drop targets.
The workbench provides some support for allowing drop actions to be contributed to pre-existing parts. However, it is tailored more towards views implemented using structured viewers, and does require both the source and dest views to enable this support. It essentially allows the source view to specify a registered action to be run when the drag is completed over an object in the destination view. See http://help.eclipse.org/help31/topic/org.eclipse.platform.doc.isv/reference/extension-points/org_eclipse_ui_dropActions.html To address Gary's use case, this support would have to be extended to editors, in addition to somehow allowing the editor to delegate to the workbench for data it cannot process, to allow the DnD-driven editor opening to still work. This is a non-trivial enhancement.
I'm not sure why you're getting the progress dialog when you specify DRAG_NONE. It would be interesting to know what's causing this. Try setting a breakpoint in ProgressMonitorDialog's constructor.
re comment 6, paragraph 1: that was exactly what I also expected and hence the tip to set event.detail= DND.DROP_NONE. >This is a non-trivial enhancement. Agree, since it would not just be about delegating drop functionality but also the whole LAF while dragging.
Another reason why having the DropTarget on some parent Composite and not on the editor itself is bad is that you will not get any drag under feedback. We are about to support the drag under effect in StyledText so that when you are dragging over the text you will see a grey insert caret at the location where the text or data will be inserted if a drop where performed. This feedback will only be visible if the StyledText widget is the control in the DropTarget. Also we will be opening up the drag under feedback mechanism in SWT so that custom widgets can add their own widget specific feedback. This could be useful in graphical editors. Nick, perhaps we should get together and talk about how drop targets are supported in the UI framework and how it can be improved.
Veronika, could you please keep me in the loop for these discussions? I'm interested in trying to remove my current 'Tracker' hack in my Trim dragging code.
OK, I'm happy to chat about it whenever works for you. I think the drag under feedback depends on the kind of drag though. For Gary's case, an insertion caret is inappropriate since the drop causes modification of the file in several places, not at any particular insertion point.
OK I would like to propose an API that would accomodate our use case. I'm volunteering BEA resources to do the implementation and contribute it. We can hopefully arrive at some agreement about what it should look like. I believe that what we need is actually to be able to receive a drop event that happens on the editor only when a particular View is in focus. I think that any drop that occurs when that View has the focus is something we want to pre-empt; whenever any other View in the Workbench window, or the Editor has focus, the drop event should be processed the way it currently is. It would also be nice to be able to delegate from the pre-empting drop listener to the pre-empted one, but I don't think that's an absolute requirement for us to be able to do what we need to do. So here's the shape of an API that I think would be serviceable. I don't know a lot about the o.e.ui data structures, or the SWT. Please give me feedback about this approach, and/or alternatives. On o.e.ui.IEditorPart (or IEditorSite?), add methods: /** * @param viewInFocus when the referenced View is in focus, the specified * drop listener receives all drop events that are received by this * IEditorPart. * Pre-empted drop events are only seen by the registered drop * listener, not by the editor itself. * @param listener this listener can ignore events it receives, or it * can do things like making arbitrary * changes to the current contents of the Editor. * In particular, it can create a DOM AST (yes I know that this is * above the level of o.e.ui, but I * want to make sure there are no impediments), and use * ASTRewrite to make changes. void registerDropEventPreemptor(ViewPart(?) viewInFocus, DropTargetListener listener); void unregisterDropEventPreemptor(ViewPart viewInFocus); The o.e.swt.dnd.DropTargetListener behaves the same as any other one. (Are there any constraints needed?)
Actually I do want a drop over the gutter to do the same thing as a drop over the Editor in this case -- that's the way that a drop from the package explorer works and to change it would confuse the user.
And the use case for delegation of the event from the pre-emptor to the pre-empted handler is, for example, supporting the drag of text from another app into the Editor; this should be processed by the Editor itself, regardless of which View in the Workbench had the focus when the Workbench itself lost focus to the source app. At least that's one approach to servicing this use case.
I am moving this bug to the UI team because I think this is more about adding a framework to UI. SWT already reflects what the operating system provides.
We've been down a similar road (early in 3.2) while trying to provide a generic mechanism to extend DnD throughout the workbench (in particular for the new common navigator). While not implemented we did come up with some (IMO) valid design rules and observations. ---------- Glazed eyes warning...;-) ------------- The following may be a bit long but I'm trying to capture the lessons learned first time around and, hopefully, to provide a starting point for the design discussions: The drag 'source' and drop 'target' are orthogonal. The drop target should only need to know the set of 'Transfer types' that it can currently accept. This means that we can split the problem into two separate, independent, extensions: - Extending a drag source by giving it the ability to offer up new transfer 'types'. - Extending a drop target to accept new transfer types and provide appropriate feedback for them. The start of a 'drag' is where the set of current transfer types gets defined. -Every- 'drag source' extension would have the opportunity to determine whether or not to add its transfer type into the list for the current drag operation (usually by examining the current selection). Since no decisions have to be made about who the 'winner' is (i.e. it's simply additive, any extension can offer up their transffer type if appropriate) this turned out to be the easy part...;-). The 'drop target' is the tough part... This is where the drop extension infrastructure has to pick which of the supplied transfer types 'wins' (i.e. the extension defining the handler for that particular transfer type will control the feedback, handle the 'drop'...). This is non-trivial, here's a few scenarios: 1) Transfer type clash resolution: Even if there's only one transfer type defined in the drag set you may have more than one drop extension that wants to handle it. For example someone may want to 'over-ride' the default handling for the 'IResource' transfer type to perform some work when files of a particular type are dropped. Worse, two contributors may want to do the same thing for two different file types (each not even know that the other exists). Who wins? The best we could come up with here was to perform an analysis of the plugin dependencies and sort them so we'd ask the 'most informed' plugin first. The idea was that if plugin "A" has plugin "B" on its dependency chain then it would be allowed to 'over-ride' B's crop target conributions (since "A" presumably knows what "B" is doing and will only interfere with it 'sensibly'). 2) The drag source offers up multiple transfer types (ie. there's a multiple, heterogeneous selection in the source). Here the infrastructure has to determine which drop target contributor to make the 'current' one. For example plugin "A" says that it'll accept 'Foo' elements and plugin "B" says it'll accept 'Bar' elements and both are selected in the source. Who wins? Well, we can do the dependency check thing and defer to the 'most informed' plugin again but that's only a partial solution since "A" and "B" may be independent organizations. Allowing the extension to define its 'priority' simply doesn't scale well since the priority 'scale' is usually fairly coarse-grained and everybody thinks that -their- contribution is the most important. To compound the problem the infrastructure has to also respect 'drag under' handling. This is where drop parts (like trees) may have areas where its legal to drop one (or more) transfer type(s) (ie. the 'Foo' folder) and other areas where its legal to drop others (ie. the 'Bar' folder). this means that the 'current' target has to be chosen during the 'dragOver' handling (ie. on every mouse move). Whew...that's a start...I'm going info-overload...;-). Feedback synchronization and in-process vs cross-process issues are still on the plate...
(In reply to comment #20) > We've been down a similar road (early in 3.2) while trying to provide a generic > mechanism to extend DnD throughout the workbench (in particular for the new > common navigator). While not implemented we did come up with some (IMO) valid > design rules and observations. > ------------ snip ---------------------------------- I believe, however, that the use case I describe above is conceptually different from these: counter to the intuitive view of the drop target wanting to process the drop event, this time the _source_, or something closely allied with it, wants to be the actual processor. Really, from a coding perspective, it would be easier to think of the gesture as completely contained within the source View, because the View knows how to do the work. (Suppose we imagine that the user right-clicked on an artifact in the View, for example, and selected "Insert into source file" from a popup menu.) But it's easier for the user to think of that gesture in terms of dragging something into the Editor and dropping it there. When he drags it, he might choose an insertion point in the file (which the drop processor would be interested in knowing), but again, the Editor would not know what to do with the drop event; the event really needs to be received and processed by something which understands the complex semantics of the gesture. That's why I suggested that the processor wants to play the role of a "drop pre-emptor", that only receives events when its associated View had the focus.
Things seem to have gone kinda silent... who should I be talking to about this potential API? Is there someone on the UI team who would like to work with us on the proposal?
Sorry, we're a little busy these days. The UI (and Text, SWT) teams are involved here and I think that is the right teams. Since it looks like whatever we do is really post 3.2 we might have gone a little silent. There are some questions that I think you need to answer so that we can evolve this discussion into a solution: Eclipse is modelled around an MVC design, so I don't see why you are putting awareness and knowledge ("View knows how to do the work") in your view. Is there a reason for this? There is a model underlying both the view and the editor and the view does not need to know that there is an editor. The view and editor need to agree on ways that they can talk to each other using the model and drag and drop can piggyback on this, as well as other views and editors piggybacking on this, however in Eclipse it does not make sense to take a single view and tie it to an editor through DnD we need to be more extensible. Can this not be specified in some generic way so others veiws and editors could play well without knowing about the existence of each other?
Mvm, I looked over the start of this thread and I may have detected a divergance between the original issue and the subsequent, more dogmatic, threads. Gary, feel more than free to correct me in the following if you don't agree. There is an underlying technical issue that prevents somebody from 'taking over' an existing Dnd operation. The view defines its SWT drop target on creation,passing in the set of 'operations' and the array of Transfer types. Once defined an outsider cannot either query for the current one (so it can delegate to it) nor can it discover what Transfer types/ops were defined on the original. This seems to be where this defect started... I faced this during my attempt at a generically extendable Dnd infrastructure and the only way around it was to provide a new 'extensible' drop adapter. Even when finished every view that wanted to support extensions would have to change their code to the new adapter in order to become extendable. Note that I do -not- believe that the SWT implementation is defective; only that it requries higher level structures built on top of it to be inherently extendable. IMO, we (jface?) are the correct level to address this at. Note that even in this environment there are still two -separate- players in the DnD game: the drag source and the drop target. However a single plugin could add both ends at the same time which is what I surmise that Gary's actually saying. (he'd be able to define his view that can provide a drag source that supplies a new Transfer type "PaletteData" in his source (palette) view -and- an entension to the JDT's drop target that would know what to do with dropped "PaletteData" elements in the same plugin).
(In reply to comment #24) ------------------ snip ------------------------------ > Note that I do -not- believe that the SWT implementation is defective; only > that it requries higher level structures built on top of it to be inherently > extendable. IMO, we (jface?) are the correct level to address this at. This makes total sense to me. Is it jface? Or would it be o.e.ui? > Note that even in this environment there are still two -separate- players in > the DnD game: the drag source and the drop target. However a single plugin > could add both ends at the same time which is what I surmise that Gary's > actually saying. (he'd be able to define his view that can provide a drag > source that supplies a new Transfer type "PaletteData" in his source (palette) > view -and- an entension to the JDT's drop target that would know what to do > with dropped "PaletteData" elements in the same plugin). Yes, this is an excellent way to characterize it. I was actually hoping that there would be some place high in the object hierarchy where a concrete method could be added, which would be transparent to subclasses, that would make it possible to register a component owned by the drag source with the target’s drop listener. That way the target drop listener could delegate back to the source component in circumstances where it understood that to be appropriate. Is o.e.ui.part.WorkbenchPart a possible place to put this? I don’t know if anything concrete could actually be done at that level, but at minimum an empty method might live there that could be overridden by various implemenations as they decided to add support for “drop pre-emption”. That would relieve all the various subclasses of the obligation to change code, until they were actually ready to support the feature.
(In reply to comment #23) ----------- snip ------------------------------- > Eclipse is modelled around an MVC design, so I don't see why you are putting > awareness and knowledge ("View knows how to do the work") in your view. Is > there a reason for this? I think we have a confusion of terminology here... I am not arguing for a violation of MVC. Let’s see if I can explain myself more clearly: As I said above, I don’t have a good understanding of o.e.ui data structures, but I believe (correct me if I’m wrong) that an o.e.uiView wants to encapsulate an mvcView, mvcModel, and mvcController. When one navigates in code from o.e.uiPart to o.e.uiPart, what one sees is the o.e.uiView, not the mvcView. I don’t see any method on either IEditorPart, IViewPart, or IWorkbenchPart that returns me an object that looks obviously like an mvcController, nor do I see anything in the o.e.ui.workbench or jface plugin that, on the surface, looks like an abstraction of mvcController. So I don’t know how to get hold of the controller associated with an o.e.uiView. But that's what I want to register my "pre-emptor" with ultimately, although perhaps offering the the API on the encapsulation (the o.e.uiPart?) is better than having to reach in and retrieve an mvcController abstraction to be able to do the registration. > There is a model underlying both the view and the editor and the view does not > need to know that there is an editor. The view and editor need to agree on > ways that they can talk to each other using the model and drag and drop can > piggyback on this, as well as other views and editors piggybacking on this, > however in Eclipse it does not make sense to take a single view and tie it to > an editor through DnD we need to be more extensible. > Can this not be specified in some generic way so others veiws and editors could > play well without knowing about the existence of each other? See reply to #24 below. Could that be WorkbenchPart?
Whoops -- see reply to #24 above.
"That way the target drop listener could delegate back to the source component in circumstances where it understood that to be appropriate." There is no way for the drop target to know through the OS drag and drop mechanism what is the drag source. It may be another application. There is already a mechanism used in JFace for creating a local transfer data type. The transfer of data is done through a Transfer subclass and not through the drag source. Please explain in more detail what you are trying to achieve. I think you may have one solution in mind but there is already a solution that is more consistent with the OS drag and drop mechanism.
Yes, subclassing Transfer looks like it will accomplish exactly what I want. The reason I am asking all these questions is because I would rather do that than write hacky experimental code that tries to do things in a way that misunderstands stuff that's already there :) Anyway, then comes the problem of where to put a jface.util.DelegatingDropAdapter, and where to provide access to it. The EditorAreaDropAdapter is constructed by IDEWorkbenchWindowAdvisor, during Workbench initialization (i.e. long before instantiation of an EditorPart). The Views seem to do drag+drop initialization when the Part is constructed. It seems though, that an API could still be offered on WorkbenchPart that allowed something like my View to register its interest in drop events for a given subclass of Transfer: something that looked a lot like jface.util.DelegatingDropAdapter#add/removeDropTargetListener(). Implementation in the Editor case would require opening up access to the DropAdapter, (currently a DropTargetListener contained in WorkbenchWindowConfigurer). Does this make sense? Or is there a better place to put it? A couple more questions: 1. Does this use case make sense to you all? Is it clear, at the user level at least, what we're trying to do? Is it a plausible case for a new API? 2. Will any of you be at Eclipsecon? If so maybe we can find a time to have coffee and talk about this... Thanks again.
>Please explain in more detail what you are trying to achieve. OK here's another scenario / problem case: I started to implement text DnD text viewers and editors (bug 11624) and run into exactly the same problem: as soon as I enable text DnD it disables the DnD support provided by Platform UI which allows to drag a file onto the editor area (which can already have an open Java or Text editor). Any ideas how Platform Text can add the text DnD support without breaking other clients like Platform UI?
I met with Gary at EclipseCon with Eric joining by phone. For 3.2, it was agreed that the best approach would be to make the editor area drop target extensible. Because we are extending the editor area and not the editor itself, this means that the extension needs to be prepared to handle the case where no editors are open or a non-java editor is active. We believe however, that it will be easier at this point to make the editor area drop target extensible than to implement a new framework for allowing editors to defer to the editor area. The side affect of this is that the Java editor will not show any drag under effect (such as a caret showing where something will be inserted on a drop)but for the current use case that is not an issue. We will need to revisit this ASAP post 3.2. I am adding John Arthorne to this bug report. He wrote an article on extending the drop target abilities for Views: http://www.eclipse.org/articles/Article-Workbench-DND/drag_drop.html John may be able to give some advice on how to make the editor area drop target extensible in the same way as occurs for views.
>but for the current use case that is not an issue. For text drag and drop (bug 11624) it is. The final solution should be in the JFace layer since it not only affects this scenario but also one where a client uses a TextViewer in his application, independent of components above JFace, like editor parts.
Just to clarify...there are two somewhat discreet problems we've discovered here: (1) Adding a drop target to an editor causes the EditorArea's drop target to be over-ridden with no chance of delegation without some framework to support it. (2) There's no mechanism through which a client can -augment- an existing drop target by making it capable of supporting 'new' Transfer types. -Both- (1) and (2) are complex enough that a general solution will need a proper design pass so they'll have to be post 3.2. For Gary's scenario I'd suggested that it -may- be possible to get the EditorAreaDropAdapter to adopt the PluginTransfer mechanism so that he could at least get partway to the full on 'correct' solution. I've already looked into this a bit and the trivial approach is out. If the current implementation of the EditorAreaDropAdapter (EADA) were based off of ViewerDropAdapter I could simply have changed the base class to PluginDropAdapter and been done. Unfortunately the EADA is currently based directly off of the SWT DropTargetAdapter and the two use different protocols to handle the drop. I'll go over this with John when he gets back but unless we have confidence in the solution's stability we won't be able to put it into 3.2 at this late date. I'll be back with more info after I've talked with John but please understand that the main foxus here now is getting M6 out...
Thanks for all your help Eric. Anything crude thing that can be done in order to enable us to develop on top of 3.2 without having to snapshot and modify plugins would be a big help. If it can't be done in 3.2 please give us as much info as you have about where the pitfalls are, so we can use it to cobble together a snapshotted solution. Also let me know when you will have breathing room to design a correct solution to the problem; we will provide whatever help we can.
I'm going to make this the 'flagship' defect for any proposed DnD extension API work since it has (by far...;-) the most info.
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.
