Community
Participate
Working Groups
Bug 123620 introduced support for dragging editors between windows. This functionality no longer seems to work. On the bright side, you can drag an editor as a detached window, which is pretty good too.
Saw this on Eclipse 4.2 M1 on Windows 7 as well. Adjusting the bug accordingly.
Yep, I need to adjust the DnDAddon to accommodate this behavior...
Hi, everyone. I tried out Eclipse 4.3 M6 for Linux and still managed to observe the behaviour. Heard that this bug was going to be address in version 4.3, so I had to try it out purely out of excitement. It'd be great though if this functionality was restored back into the software
I just took a look into this and while it's fairly simple to implement the DnD behavior (just make the check in DnDInfo's 'getModelElement' check that it's the same *app* rather than the same top level window) there are are few subtle details to be worked out. 1) In order to avoid confusion we should be limiting this to 'editors' only. Otherwise you can make strange perspectives that, for example, have two Outline views...this is likely doable without too much difficulty. 2) We'd need to trap and adjust the EditorRef for the editor that's been moved since moving it from one window to another means that it has effectively changed form one WorkbenchPage to a different one. This is a bit more problematic, we're already looking into this code however since we have other defects relating specifically to EditorReference management, perhaps we can blend the logic required for this defect into the fix for that one...
I see thanks for taking a look at it. Hope the feature returns soon. At any rate, I'll just go back to 3.8.2 for the meantime as I frequently drag around open editors in one window to another
I've pushed the following to Gerrit: https://git.eclipse.org/r/18991 This is a change set against R4_3_maintenance...
Committed: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=92735f56139b74c532931eb26ab6a98017a1aec9 This is a good first cut but there are two remaining corner cases: 1) Our current drag strategy is to drag the whole stack if the element being dragged is the only visible element and it's *not* the last editor stack. This means that dragging the only editor from a stack in the *split* editor doesn't work. Should be easy to fix by never dragging the while stack if the initial element is an MPart rather than a MPlaceholder. 2) Dragging the editor to the new window doesn't fix up the EditorRef's of the two WorkbenchPages. We expect this to be managed by a new approach to handling both view / editor refs by listening to model additions / removals.
Committed: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=76c0a2c25682ae4da4c19146309faff7c8c80440 Which fixes corner case 1) from above
BTW, we likely won't be able to back port this whole fix but at least the change in the DnDManager should go back to 4.3.2 since it's likely broken in multi-window cases...
M4 is done...
Committed: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=57da556a74d6ef26a492a5e92ab61ef0e9ab2b63 This fixes scenario 2) by adding a listener in the workbench page that detects new parts being added and ensuring that any ones with EditorReferences get their page updated...
Marking FIXED...
Verified in 4.4.0.I20140303-2000.
This feature got pulled out due to too many issues. See bug 445305 and duplicates.
(In reply to Dani Megert from comment #14) > This feature got pulled out due to too many issues. See bug 445305 and > duplicates. Reverting the following commit will enable it again: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=b29fc6b1033e97e1d7babe4e5b917106f1c17b8c
Mass move to 4.7 as M7 is approaching. Please move back in case you are planning to fix it for Neon.
Bug 445305 suggests that the editor has a incorrect parent (shell), but that is not the case. At least the following issues exist: 1. CompatibilityPart does not emit firePartClosed when the editor is moved. This is fixable by also listening to UIEvents.UIElement.TOPIC_PARENT 2. KeyBindingService#registerAction adds a LegacyHandlerSubmissionExpression which binds the keys to the current shell. All key bindings will not work if the editor is moved to another another window. Setting shell to 'null' makes key binding work in the Java editor. The Manifest editor remains broken probably caused by a WorkbenchWindowExpression.
*** Bug 384308 has been marked as a duplicate of this bug. ***
More issues: 3. ActionBars are hard wired to the window in which an editor is opened, they are not moved to the other window when an editor is moved. 4. Anything implementing the IPartListener cannot be notified that a part is hidden in the current window. It might be needed to send partClosed events if a part is hidden. Related to issue 1. The easiest work-around is to close the editor in the first window and re-create it in the second window. This means that dirty editors cannot be moved. This can be realized by calling EPartService#hidePart, EPartService#showPart in StackDropAgent.
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.
Bug still occurs. Still very annoying with multiple Eclipse windows.
