Community
Participate
Working Groups
Drag an editor tab slightly inside the editor area to get 1:2 split. Editor area gets split into two on drop although it's supposed to split only if the Ctrl key is pressed.
Committed (on Sergey's behalf): http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=e65963bf5ab77d2568e1c5fbf92e0a09ab253e4e This corrects the check to ensure that the Ctrl key must be down before entering this code path.
Eric, Have you taken a look at a more comprehensive fix in https://git.eclipse.org/r/#/c/23699/?
Eric, see the new Gerrit review.
Sergey's been cleaning the code: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=119188d55913bc29b0f1180ab896b9ffc59bf310 Thanks dude !
One more, even better... http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=931f731ad02d4dbd13d39f288043001d04801459 This works quite well...now we should f see if we can do the same at the 'edge' between the perspective stack and outside perspectives. If you open the Welcome screen and then maximize the editor area you can see that the Welcome view stays visible. This is because it's outside of the perspective Stack. The same rules should apply in this case as to only being able to move a view outside of a perspective when the Ctrl key is pressed. Sergey, if you want I'll open a separate defect for this and we can mark this one as 'done', thanks a lot.
The DnD code is suffering from two major problems: 1. There is no single source of truce for both, visual feedback and drop behaviors. A discrepancy between showing the outer rectangle and splitting the editor area was fixed by commit http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=931f731ad02d4dbd13d39f288043001d04801459, but there is still a discrepancy in determining the docking location. I'll file separate a separate bug for it. 2. I many places nontrivial logic is not accompanied by JavaDoc or regular comments, which makes it hard to determine the intended behavior in cases when the code deviates from it. It makes sense to create a separate bug for dragging a view outside of the perspective. I'm not sure what the desired behavior for it is, and how the current behavior is different from it.
Filed bug 431182 for another inconsistency between the dragging feedback and the drop behavior.
I'll be taking a closer look into this: We've introduced a serious regression; now any attempt to split a stack outside the editor area results in the stack being placed *outside* the perspective stack (i.e. it's completely useless). Looks as if the 'onEdge' is somehow locked to 'true' since it even occurs without having a 70:30 split feedback...
OK, here's the pseudo-code for what we want: There are three locations that the dragged element can be: - In the shared area (the MArea, generally editor stacks) - In an MPerspective's presentation (most Views) - Outside any perspective (i.e. outside the MPerspectiveStack, the Welcome view) There are two 'edges'; one on the inner border of the MArea and one on the inner border of the MPerspectiveStack. These are there to allow placing a stack so that it occupies the full 'edge' regardless of what the rest of the structure looks like (i.e. you have two editor stacks one above the other but want to make a new one that occupies the complete right side). 'Edge' based drops are 70 : 30 in ratio. As far as dropping an element in a location different from where it started the general rule is that the dragged element should end up in the same 'location' it started in unless: - The modifier is enabled - The drop is *explicitly* in another location Note that being on an 'edge' is *not* a pre-requisite to move an element across a boundary, just that the drop location be ambiguous. For example if there is only one editor stack in the MArea and you split it what happens will depend on what you split it *with*: - If the drag element started in the MArea then the resulting stack is in the MArea ('relTo' == the editor stack) - If the drag element started in the Perspective then the resulting stack remains in the perspective presentation ('relTo' == the MArea's MPlaceholder). The use of the modifier simply chooses the alternative to the default in ambiguous cases. An unambiguous case is one where there is no choice: - Dropping directly into some existing stack - Splitting an explicit stack in an already split location since the locations must by rectangular (this is a case where using the 'edge' drop would work). Checking for edges has to take place first, allowing edge drops regardless of the actual structure. Now I'll go see how closely the code matches this...;-).
Reverted the previous commit for this: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=0b99b1fab139913962574490550c226b51023c9b While this still has issues on the 'edge' conditions you can at least split a stack normally.
Why not 4.5 at least?
+1 for that...
Eric Moffatt pointed me from my bug report to this change to see if this has done any good. Problem described in bug 430403 seemed to become partly worse from this solution (tested with I-Build from 8th April).
I'm in the process of refactoring this code (hopefully for M7). The current code has too much 'history' (i.e. cruft) left over from its original implementation.
Committed: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=f0a32e7f390021ef254021b5edfaa32ee64d5673 This fixes *many* of the issues with the current implementation, specifically dragging views to the edge of the presentation. It's still a bit flakey with its control key handling (but still better). Since this is so late and it's a re-write I've left the original SplutDropHandler in place until we're satisfied that the new code is release-worthy.
Sergey, if you have time let me know if the new code is more understandable than the previous one...just want to know if I've made this easier to fix in the future...;-).
(In reply to Eric Moffatt from comment #16) The change is a definite improvement, but... 1. The code is not easier to understand since many nontrivial methods lack comments. Consider for example: private boolean isModified() { return dndManager.isModified && (relToElement instanceof MArea || relToElement instanceof MPerspective || dndManager .getModelService().isLastEditorStack(relToElement)); } Figuring out what the condition really means is not for the faint of heart and is definitely not implied by the name of the method. Even the SplitDropAgent2 class itself doesn't have JavaDoc. 2. There are still cases when the dragging feedback is not consistent with the drop behavior. To reproduce: a) Open few editors. b) Split the editor area by dragging an editor with Ctrl pressed. c) Drag the editor back to the rest of editors. The feedback shows two single-line rectangles as when dragging within a common editor area, but the drop result is two editor areas. 3. It is still possible to drag an editor outside of the perspective without Ctrl key pressed. There is no visual indication that something unusual is happening.
Committed: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=db974cf81b37f24a3df4eb9be2cdeb599a2497b7 This fixes what appears to be a regression in SWT; pressing the CTRL key was causing the Display.getCursorControl() to return null. This is a 'fix' that presumes that if the cursor hasn't moved then there's nothing that need updating. P.S. Thanks Sergey, I'll try to update the comments during RC...
Oops !! Thanks Paul (on Linux this was throwing an NPE... http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=d1edc537fe71fef0a3ce8a60f8a7baba0407bbaa
Verified in 4.4.0.I20140528-2000
