Community
Participate
Working Groups
If you move an editor to another pane (by drag&drop of its tab), the previously visible editor (of the origin pane) does not necessary remain visible. The editor which will gain visibility will be the one which was originally at the left of the moved editor, or the new first one if the moved editor was the first. This is a regression from Eclipse 3.7. Steps to reproduce: [] represents the visible editor of a pane, | represents a split pane. 1. Open 3 editors and select the first one: [A], B, C 2. Drag&drop editor C in order to split the screen vertically. Result: A, [B] | [C] Expected result (as in Eclipse 3.7): [A], B | [C] (editor A should remain visible as before) Even worse: if you have a lot of editors such that after the split, the first pane would not be able to display all of them, the visible editor's tab might disappear. Steps to reproduce: {} represents the list of editors whose tab is not visible (only accessible through the Ctrl+E list) 1. Open a lot of editors and select the last tab: A, B, C, D, [E], {F, G} 2. Drag and drop the first editor in order to split the screen vertically. Result (for example): [B], C, D, {E, F, G} | [A] Expected result (for example): B, C, [E], {D, F, G} | [A] (editor E should remain visible as before, the other visible tabs should probably be the most recently focused ones) Moving editors is usually done to get visibility to something that was previously hidden, but if the previously visible editor gets hidden afterwards this is very counter-productive…
Wondering if this is a UI bug.. changing from SWT to UI for comments.
It's a UI defect, I'll find the root defect once I start to look at 4.3 defects once 4.2.2 is released (the root cause is that we don't respect the MRU 'history' when determining which tab to make active once the currently active one has been removed...).
I think it's not really a defect. We *do* respect the MRU 'history', provided that MRU is enabled. It can be enabled in the css: .MPartStack { ... swt-mru-visible: true; } With this setting the scenario from the description works as expected. Please also see bug 387876 for further details.
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. If you have further information on the current state of the bug, please add it. 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.
