Community
Participate
Working Groups
When I have a TabFolder with Tabs A, B, C, D (in this order, for example Java Editors) and I'm viewing Tab B and like to compare it with Tab D I'm selecting Tab D and drag it to the side of Tab B to have the are split and view them side-by-side. This is working, but after completing the drop, Tab C (the last tab) is selected in the original Tab Folder and not Tab B (the previously selected) as it was in eclipse 3.x. I have to find Tab B again and this is very tedious if it's a longer list and if I don't remember the exact name of the Tab.
I'll defer this until we finish the service releases. I'm still wondering if this is an issue...what if the original tab order had been a, c, b, d ? What I'm implying was that with the tab order you describe the current behavior is 'wrong' but might it not be 'right' if the order were different ?
Thanks for looking into this Eric. I described the Tab-Order from left to right or 0 to n concerning the tab folder. The tab n is always selected after the drop completes, but in 3.x it was the timely last selected (LRU) tab of the tab folder. This is the behavior I do expect. If I do have tabs 0 to 100 and tab 3 was selected and I move tab 5 to a new location, than tab 100 is the new selected tab. Not nice to navigate back to 3.
Yes, I now understand...there's another defect open on this (can't seem to find it at the moment). I certainly agree that the stack's MRU order would be the most appropriate thing to use. Looks like I may have to arrange for a stack to keep a 'local' MRU list, not too hard but note that this will not be persisted (i.e. on the next restart the MRU list will contain only one element, the one currently on top).
The other one is bug 387678. Bug 387678 comment 3 describes similar workflows.
First thoughts on a solution here are to have the StackRenderer keep track (in 'transientData'?) of the MRU list. Then the DnD code could use this to determine which part to activate if the current one leaves the stack. I suggest transient data because in general there's no point in 'remembering' this type of thing across sessions (because the user won't remember either).
Sorry, I fully disagree with considering MRU order as transient data (see e.g. bug 149476). Even if I don't remember the full MRU order all the time, I often do remember the top few items. That could be the last few editors I worked with before I had to restart. Or I have view stacks that contain rarely-used views, and I don't want any of those come to front just because I close another view in the same stack.
Another use case where selecting the last tab is clearly wrong: - open a few editors and select any editor tab except for the last one - Window > New Editor - move the newly opened tab away into another part stack (or split editor area) => original stack doesn't show the other instance of the duplicated editor
I believe this is not a bug, but a feature that can be controlled by CSS. Please note that MRU is already implemented in CTabFolder, and can be enabled by swt-mru-visible CSS property of MPartStack CSS class. The relevant CSS file is e4_default_<OS>.css (for example e4_default_win7.css, in my case). After changing the CSS property value to true, the scenarios described here worked as desired, with the most recently used Part being activated, as opposed to the rightmost one. Hence, I believe this issue does not require a fix.
Thank you Piotr for pointing this out. Changing swt-mru-visible: false; to swt-mru-visible: true; in all the .css files under org.eclipse.platform_4.xxx\css will restore the MRU behavior for the TabFolder. Two more comments on this: 1. I think swt-mru-visible: true; should be made default in the provided css files. (I even see a 'e4_default_mru_on_win7.css' in this folder, which does not seem to be used at the moment.) 2. I always think of MRU as behavior and not as a style, thus I'm a bit surprised that it has to be changed in the css. If I changed the style, I have to remember to check this property too.
I believe that the CSS file with "mru" is just something you can use to substitute your original (default) file to have the MRU behavior. I could probably make a patch that would make MRU default, if it's tedious to maintain this setting manually.
Bug 388476 is about how to configure swt-mru-visible in the UI.
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. If the bug is still relevant, please remove the stalebug whiteboard tag.
