Community
Participate
Working Groups
At some point during Eclipse 4.x, there were many regressions in the Drag & Drop system. This is an umbrella bug to track the regressions between Eclipse 3.x and 4.x. Most notable regressions: - Dragging to the edge (the last pixel) of the workbench window or to the edge of the Monitor's display area used to indicate a split that would span the entire width or height of the workbench window. This drop region is no longer working. - There used to be a drop region in the center of a stack (which occupied most of the stack's area) which would cause the dragged view to stack with the other views in that stack. Currently, dragging to the center of a stack is causing a split. This is not useful since stacking is much more common than splitting. - Selection of drop targets should be purely a function of the cursor position and the nature of the dragged object. Currently, the path the cursor followed to get to its position also affects the drop target selection. If you move the cursor somewhere else and then back to the same location, it will often select a different drop target. - A part called "Drag placeholder" often appears in the layout after drag/drop operations. - Drag cursors are not working on GTK. - Dragging a part back to the center of its own stack should cancel the drag operation. Currently it causes a split. See section 3.6 of this document for a diagram of the two missing drop targets: https://eclipse.org/articles/Article-UI-Workbench/workbench.html
New Gerrit change created: https://git.eclipse.org/r/71849
The first item, above, is bug 431894.
Another problem: Sometimes, when dragging an editor tab to the right, there is no target feedback in the position after the rightmost tab and, in more rare cases, before the rightmost tab. It looks like the problem is easier to reproduce right after Eclipse startup when there is a chevron on the right end of the tab row.
Another problem: the drag-over regions are wrong for splits on rectangular stacks. If you create a very wide but short stack then drag close to the top-left corner but much closer to the top than to the left, it should do a top/bottom split. However, it does a left/right split instead. It seems like the drag regions form an X at the center of the view aligned with the line X=Y, but they should form a region more like what is shown in the Inside the Workbench diagram (section 3.6): https://eclipse.org/articles/Article-UI-Workbench/workbench.html We can use Geometry.getClosestSide to compute the correct split location.
New Gerrit change created: https://git.eclipse.org/r/77824
New Gerrit change created: https://git.eclipse.org/r/77827
Since recently dragging an individual view is no longer possible, instead the entire view stack is moved. Observed running M20160817-0420 as well as I20160824-1429 - both on GTK3 in Kubuntu 16.04.1
(In reply to Stephan Herrmann from comment #7) > Since recently dragging an individual view is no longer possible, instead > the entire view stack is moved. > > Observed running M20160817-0420 as well as I20160824-1429 - both on GTK3 in > Kubuntu 16.04.1 This is weird. Could you please provide more information, like a screenshot or a list of steps to reproduce? Regards.
(In reply to Patrik Suzzi from comment #8) > (In reply to Stephan Herrmann from comment #7) > > Since recently dragging an individual view is no longer possible, instead > > the entire view stack is moved. > > > > Observed running M20160817-0420 as well as I20160824-1429 - both on GTK3 in > > Kubuntu 16.04.1 > > This is weird. Could you please provide more information, like a screenshot > or a list of steps to reproduce? Screenshot won't tell a lot, would need a video. Steps are simply: try to grab the title bar/tab of a view that sits in the same stack with other views and move it to some other place, either to create a new stack or move it to an existing stack. When the bug occurs all views from the source stack will be moved, making the original (now empty) stack disappear. After experimenting a bit more it appears to be a problem in actually grabbing the source thing. On many attempts drag will not start at all, indicating that nothing valid has been selected. When drag starts it most of the time applies to the entire view stack, only in some lucky cases it correctly picks the individual view (so, yes, that is still *possible* with a lot of luck). Note that I'm on HiDPI on this machine. @Sravan, does my observation match to what you mentioned?
(In reply to Patrik Suzzi from comment #8) > (In reply to Stephan Herrmann from comment #7) > > Since recently dragging an individual view is no longer possible, instead > > the entire view stack is moved. > > > > Observed running M20160817-0420 as well as I20160824-1429 - both on GTK3 in > > Kubuntu 16.04.1 > > This is weird. Could you please provide more information, like a screenshot > or a list of steps to reproduce? > > Regards. I think I've recently filed a similar bug (if it's the same, please feel free to close it as duplicate), https://bugs.eclipse.org/bugs/show_bug.cgi?id=500694 I've uploaded a video that shows this problem: https://youtu.be/GRv5qyEqArQ Note how no feedback is given in the package explorer (and no dragging is executed) and later in a tree editor, the dragging is completely wrong
(In reply to Lorenzo Bettini from comment #10) > I think I've recently filed a similar bug 500694 (...) > I've uploaded a video that shows this problem: > > https://youtu.be/GRv5qyEqArQ > > Note how no feedback is given in the package explorer (and no dragging is > executed) and later in a tree editor, the dragging is completely wrong Thanks Lorenzo! In the video seems HiDPI DnD can't drop to the correct target. That bugreport, seems not a dup, and is now linked to this "umbrella bug". Perhaps that is related to GTK too. Adding Leo in c/c as I think he might be interested in this.
(In reply to Patrik Suzzi from comment #11) > (In reply to Lorenzo Bettini from comment #10) > > I think I've recently filed a similar bug 500694 (...) > > I've uploaded a video that shows this problem: > > > > https://youtu.be/GRv5qyEqArQ > > > > Note how no feedback is given in the package explorer (and no dragging is > > executed) and later in a tree editor, the dragging is completely wrong > > Thanks Lorenzo! In the video seems HiDPI DnD can't drop to the correct > target. > That bugreport, seems not a dup, and is now linked to this "umbrella bug". > > Perhaps that is related to GTK too. > > Adding Leo in c/c as I think he might be interested in this. There were subtle changes in coordinate management in gtk3.8/3.10. I sometimes find that on gtk3.6/3.8 certain DnD behaviour worked, and later in Gtk3.10+ things break. For example part-dragging broke in 3.8. I find it difficult to narrow down a problem from Platform.ui to SWT. Any SWT snippets to reproduce problematic behaviour would be very helpful in narrowing down issues. If you need something tested on various Gtk versions, please feel free to ping me, I have almost all gtk versions compiled on my system. I'm currently investigating the Part-Draging business Bug 498217 - [GTK3] Dragging parts does not show rectangle
(In reply to Leo Ufimtsev from comment #12) > Gtk3.10+ things break. For example part-dragging broke in 3.8. Correction, 3.10.
Here is another regression that appeared only in Oxygen 4.7 M2, M3 and M4. I submitted Bug 509729 but here are the details again. Basically whenever you have more than one window with more than one editor or split editors. Then restart eclipse. In one of the windows you can no longer drag the editors at all. Either to reorder or drag to the side to split the window. To reproduce Open Eclipse Open two files in the editor. Drag to the side so that you can have a split view of the editors. Click on Window > Open New Window Open two other files drag one of the editors to the side. Restart Eclipse Now the two windows should reopen but in one of the windows when dragging the editor tab to the side you will always get the unmovable icon and you will not be able to move any of the editors in that window anymore.
It's been a while since I've looked into this and related bugs, but I thought I should re-raise this one as it's cropped up again (after being 'fixed'): https://bugs.eclipse.org/bugs/show_bug.cgi?id=384810 (marked as duplicate of https://bugs.eclipse.org/bugs/show_bug.cgi?id=384308) This is a bug I originally filed in 2012 describing a major regression in behaviour between versions on Eclipse. The change described in this original bug from 2012 became worse once 'fixed' - you could only drag a file window to the file windows tab bar of another window, not the whole editor window. (making reference to https://www.eclipse.org/articles/Article-UI-Workbench/workbench.html) I.E. You used to be able to drag an EditorReference to an iEditorPart or the workbench window and it would move the file/tab from one editor instance to another. In 4.2.x (Indigo) you had to drag an EditorReference to the EditorReference tab bar to move the file. Now, once again, this no longer works in Photon.
(In reply to Stefan Xenos from comment #0) > At some point during Eclipse 4.x, there were many regressions in the Drag & > Drop system. This is an umbrella bug to track the regressions between > Eclipse 3.x and 4.x. > > - There used to be a drop region in the center of a stack (which occupied > most of the stack's area) which would cause the dragged view to stack with > the other views in that stack. Currently, dragging to the center of a stack > is causing a split. This is not useful since stacking is much more common > than splitting. Are there any news regarding this issue? We develop a RCP application and plan to update to the newest Eclipse. This regression is a major drawback.
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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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. -- The automated Eclipse Genie.
I believe this bug should be reopened. The second and the last points are two major regressions, in my opinion. Or should I open two separate tickets for them?
I added an issue on GitHub related to this bug: https://github.com/eclipse-platform/eclipse.platform.ui/issues/677
