Community
Participate
Working Groups
In the workbench layout looking like this ------------------------------------------ | V | | V | | i | | i | | e | Editor area | e | | w | | w | | | | | | s | | s | | t |------------------------| t | | a | | a | | c | | c | | k | View stack 2 | k | | | | | | 1 | | 3 | ------------------------------------------ Drag one of the editors to the lower part of the view stack 3, approximately 1/6 from the bottom, in the middle horizontally. The dragging feedback should show the view stack 3 split into two equal size rectangles, one above the other. Release the mouse button. The resulting layout is ------------------------------------------ | Vi | | Vi | | ew | Editor area | ew | | | | | | st |------------------------| st | | ac | | ac | | k | View stack 2 | k | | 1 | | 3 | |----------------------------------------| | | | Dropped editor | | | ------------------------------------------ The drop result doesn't match the dragging feedback. Not sure what the intended behavior is.
I cannot reproduce the bug. After drop the result always match the dragging feedback. Tested in Windows 7 with Eclipse 4.3.2 and 4.4 M6.
Sergey, do you have your previous fixes in place when you get this ? Wojciech, if you can would you re-test with either last night's N-build or run an inner with the latest code ? We've just made some changes here and it's possible we've affected the behavior...
Eric, Indeed it can be reproduced in the latest nightly build - N20140325-2000.
So the recent commits have introduced a regression I guess with the work for bug 430662. I'll take a quick look and see what I can find. Sergey, the basic idea is that we want to inhibit the user from putting the presentation into shapes that weren't available in 3.x 'accidentally' so the intent is to guard against these by requiring the 'modified' to be set. There are two cases... 1) Splitting the Editor Area (with an editor / starting from within the EA) should always result in the new stack being inside the shared area unless the gesture is unmistakably outside the shared area (i.e. splitting the stack containing the Package Explorer as opposed to a stack *in* the shared area. 2) Moving a view / stack out of a perspective and into a 'global' part of the presentation (i.e. where the 'Welcome' view shows up) which is what we're seeing here I think. If we're going to go over this I'd probably start by removing the '70/30' handling altogether since it's a leftover from when we didn't guard these changes with a modifier and used the feedback instead (which proved woefully insufficient...;-).
(In reply to Eric Moffatt from comment #4) I think we should start from making sure that both, the dragging feedback and the dropping behavior are controlled by a common piece of code so that a discrepancy like the one described in this bug is simply impossible. Once we have a single source of truth, we should write a detailed description of the desired behavior and then adjust the code so that it matches that description. Do we have any DND tests?
(In reply to Sergey Prigogin from comment #5) > (In reply to Eric Moffatt from comment #4) > I think we should start from making sure that both, the dragging feedback > and the dropping behavior are controlled by a common piece of code so that a > discrepancy like the one described in this bug is simply impossible. Once we > have a single source of truth, we should write a detailed description of the > desired behavior and then adjust the code so that it matches that > description. > +1 for this...in retrospect the DnD is over engineered because I'd hoped to give something better but ran out of time...moving to something simpler for the feedback (rather than tying it to the DnDManager might be a good start ?). > Do we have any DND tests? Sergey, if we had tests we wouldn't be in this state...both :-) & ;-(.
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.
