Community
Participate
Working Groups
We need to support the same level of customization as the legacy workbench window. This defect will track the work for this item. Need to be able to (at least): - Drag a part from one stack to another, including insertion at a particular index - Drag ToolItems from one Toolbar to another, including insertion - Insert a Part or Stack into a newly created slot in the sash structure, includes the creation of new PartSashContainers if necessary. - Move any trim element to any other place in the trim. This has to include the ability to drop onto 'virtual' trim sides (i.e. ones that haven't actually been added to the model yet. Note that ToolBars are trim elements so this covers moving TB's as well. - Click and drag to start; ESC to cancel
Committed in >20100212. Added the ability to drag parts between stacks and items between toolbars. Note that the element being dragged is still contained within the model so that it can be 'live' (i.e. it still has access to the Window's context...). Susan, the code is essentially broken into 4 classes and I'm pretty sure they'll change somewhat over time...;-) DragAndDropUtil: Contains code that will gather up model-related information from the current cursor position. I suspect that this functionality may end up in the model service. DnDManger: This is the SWT listener logic. It controls the DnD gesture's start and finish as well as controlling the feedback during a drag. This feedback currently comes in three independent manners: - cursor feedback (currently a 'hand' for a valid drop location and a 'no' if the location is not valid) - through a specialized MWindow that contains the element being dragged and tracks with the cursor (see DragHost below). - through graphics on an 'Overlay' shell. Currently this just does a bad job of drawing rects around the current tab 'item'. DragHost: this is a class that creates a special type of 'MWindow' (identified by being tagged with DragHostId). The actual creation of the shell is done in the WBWRenderer which is where you can see the 'Alpha' value being set. Note that we could likely set the alpha value using CSS if that's better. We can also mess with any number of funky values (scaling, rotation, fades) to get the look we want. Overlay: This is another form of feedback. This is a specialized shell that sits on top of the 'base' window and allows *any* type of graphics to be drawn on it. We have to be careful to match the 'Region' to the actual displayed graphics since this allows the underlying shell to be shown 'though' the overlay.
Adding Susan.
Remy, if you synch this should allow dragging of parts from one stack to another in the compatibility IDE as well.
Created attachment 170080 [details] Patch that updates DnD to handle placeholders
Still need to add support for dragging stacks (mostly to facilitate detached windows...
Created attachment 172809 [details] Don't allow drops onto elements not in the same top level window
Committed in >20100625. Applied the patch.
Eric, do you want to close this bug? I think the major work has been completed, yes?
DnD functionality is not yet complete: 1. Open a fresh e4 workbench 2. Detach the Package Explorer 3. Try to restore the original layout by dragging the Package Explorer back to its previous position Result: Not possible. Also missing: - Dragging a whole stack by dragging the stack header - Dragging trim bars - Dragging a part out of a trim bar - Dragging a part into a trim bar - Reordering of parts inside a trim bar I think this should be fixed for 4.0, if possible (at least the above scenario with the Package Explorer).
Stefan, I'm re-working the DnD right now to at least address the ability to drag views back into the main layout... Most of the rest of the scenarios you mention will likely have to wait until post release...
Created attachment 174791 [details] Fix DnD issues This patch has three parts: Wire up the StackDropAgent for special handling to allow dragging Views back into an empty editor area (while still allowing them to be added to the stack itself if desired..drag near the top). Change the SplitDropTarget to correctly create a stack of the correct type depending on the type of part being dragged as well as ensuring that if we are splitting the editor area with a *view* that we ensure that the split occurs in the main layout (not the EA). Change the CleanupAddon to handle removing empty Editor stacks (except for the last one). The change in LazyStackRenderer is just some safety code that I want to leave in because anything that sets a part's Context parent to 'null' is guaranteed bad...;-).
Susan, you may want to try some of the other scenarios you were mentioning to see if there are still any holes...
Eric, can you have a look at bug 320344. This bug still exists after the patch.
(In reply to comment #13) > Eric, can you have a look at bug 320344. This bug still exists after the patch. Oops. Sorry for the missing question mark. This was unintentional.
I played with the patch a bit. I verified that the Package Explorer scenario in comment 9 is now working (whereas before it was not). There is a big improvement in the ability to get detached windows back into a new spot, so I think this fix is worth doing. Also verified that you can drag a view into an empty editor area and it creates a new stack next to it. There are still some holes, but nothing I see as stop-ship. I do think we should describe the limitations on the missing features page. Note that I'm just listing problems I found, I did not check to see how the behavior was before the patch. 1. Open two files (two editors in the EA). 2. Try to drag one of the editors as a detached view. ->Doesn't work. Known issue. We should doc this. 3. Now drag one of the editors into its own stack (I created one to the right of the outliner). 4. From the new stack, try to drag the editor as a detached window ->You get an empty detached window and the editor is gone. 1. Open two files (two editors in the EA). 2. Drag one of the editors into the outliner stack. 3. From the outliner stack, try to drag the editor as a detached window ->You get an empty detached window and the editor is gone. These empty floaters are a nuisance because you can't close them and they appear on top, but reset perspective seemed to clear it up (at least until bug 320320).
Created attachment 174848 [details] Revised patch... 1) Prevents directly detaching an Editor 2) Only makes stacks inside the Editor Area 'EditorStacks'. This is to prevent the having 'maximize' buttons on stacks that aren't in the EA.
Created attachment 174849 [details] Ooops, last patch contained some unfinished TrimStack work...
- do we need a try..finally in DnDManager.startDrag so that the cleanup code is guaranteed to be run? - there's a sysout in DnDManager.startDrag - look for visble children (instead of all children) when checking if you're dropping into the same stack
One more thing Eric and I realized while testing the patch: we're creating "an endless hall of mirrors (erm, part sash containers) over time. Tracked by bug 320344 .
Yet another thing (but not related to the patch): On the Mac, I sometimes don't get the rectangle feedback (only the drag cursors).
We need a tracker.dispose()
(In reply to comment #21) > We need a tracker.dispose() see also bug 320341 (awaiting Eric review) as it will touch the same code. I'm still testing this patch. Source review is a bit hard to follow for me for the hairy stuff (SplitDropAgent, etc.). One nit: I was initially confused by this comment in StackDropAgent (line 61) // If we're in the 'tab area' then allow the drop, else split Presumably the "else split" is handled by virtue of returning false and letting the SplitDropAgent handle it. So I prefer: // If we're in the 'tab area' then allow the drop, else assume another // agent, such as split, will handle it.
Created attachment 174903 [details] Patch revised according to feedback This also contains the fix for 320344 as well as a change to where the DetachedDropAgent places the rect relative to the cursor. I've included some CleanupAddon work as well this time that will remove empty editor stacks unless it's the last one...
BTW, setting the stippled to true seems to have trashed the feedback when dragging in the tab area (what used to be a vertical line is now just two dots). We can either revert this or I can see if there's a rectangle width that works...
Created attachment 174906 [details] stippled position marker For me, the stippled position marker works fine on Windows 7 (before patch). See screenshot.
(In reply to comment #24) > BTW, setting the stippled to true seems to have trashed the feedback when > dragging in the tab area (what used to be a vertical line is now just two > dots). Eric, I have just tested your patch. I works fine for me. Rectangle is as before the patch.
Created attachment 174913 [details] screenshot of stippled marker with patch (win7) looks ok for me with patch on win 7. If this proves troublesome on other platforms we should remove it and punt the stipple bug to post 4.0. Testing latest patch...
Eric, after the patch I have just discovered a bug (don't know if it existed before): 1. Detach the Package Explorer 2. Detach the Package Explorer again, i.e., drag it off the detached window and drop it outside the workbench window. Result: Package Explorer will disappear. Detached container window empty. NPE on the console.
Created attachment 174916 [details] screenshot maximizing an editor area caused two editor areas to get maximized. I created the second one in the course of dragging an editor to a new stack. Is this maximize behavior expected?
This is how it works in 3.6. I find this useful.
(In reply to comment #28) > Eric, after the patch I have just discovered a bug (don't know if it existed > before): > > 1. Detach the Package Explorer > 2. Detach the Package Explorer again, i.e., > drag it off the detached window and drop > it outside the workbench window. > > Result: Package Explorer will disappear. Detached container window empty. NPE > on the console. Same result before the patch. Package Explorer will disappear. On 3.6, it realizes that this is just a move (the cursor changes accordingly to indicate it's not a stack manipulation, just a move).
(In reply to comment #30) > This is how it works in 3.6. I find this useful. you are right. For some reason, having the view stuck in there is confusing me. I was thinking we have two editor stacks, not a split, and therefore only the one stack should maximize. But this is an implementor's point of view...to the end user that distinction doesn't matter anyway.
(In reply to comment #32) > (In reply to comment #30) > > This is how it works in 3.6. I find this useful. > > you are right. > For some reason, having the view stuck in there is confusing me. I was > thinking we have two editor stacks, not a split, and therefore only the one > stack should maximize. But this is an implementor's point of view...to the end > user that distinction doesn't matter anyway. Well, the appearance is not quite right (both editor stacks have a maximize button) but at least we know exactly what's going on. This should go on the list of things to go over once 4.0 has shipped.
(In reply to comment #31) > Same result before the patch. Package Explorer will disappear. Stefan, could you please open a new bug for this, since it is not a regression introduced by the current patch?
(In reply to comment #34) > Stefan, could you please open a new bug for this, since it is not a regression > introduced by the current patch? I'll open a bug for this. Another bug: When dropping a view into a split editor area, the preview rectangle will appear only on one of the editors, but the view will be dropped alongside both editors. In other words, the rectangle should cover the whole editor area.
(In reply to comment #35) > Another bug: When dropping a view into a split editor area, the preview > rectangle will appear only on one of the editors, but the view will be dropped > alongside both editors. In other words, the rectangle should cover the whole > editor area. I have opened bug 320557 for that.
Nice feedback! We know we need an actual 'editor area' visual container to cover off the button issues and removing the confusion as to what's 'in' or 'out'...later (I'm gonna beg bodgan for a special CTF (superclass?) that draws a border and manages the min/max buttons...tb?) I'll certainly look into the detach a detached case (wire it off if it gets too deep). Nice piclup on the rectangle for the dragging a view into a split editor area, fix should be just to base the rect calculation of of what would be the 'relTo' on the drop (i.e. make a 'getRelTo' method and use it in the rect calcs).
+1
Committed in >20100722. Applied the patch. I'll wait a bit before marking this 'fixed' ;-)
(In reply to comment #39) > Committed in >20100722. Applied the patch. > > I'll wait a bit before marking this 'fixed' ;-) Time to mark this fixed.
Re-opening for polish work...
Committed in >20110224. Checked in changes for a new approach to DnD...at least some more work will be needed before M6 ends but at least I can start with this code...
Removing outdated target milestone.
I'm going to close this defect. We already have a few others open for Luna work...
