Community
Participate
Working Groups
When you get a lot of tabs open on a notebook, a little sideways spinner appears so you can scroll through the tabs. This is *dead* wrong: * It provides sequential, multi-click access to the tabs. The number of clicks is related to the number of tabs. From a human interface perspective, this is bogus. * The fact that Swing does this in 1.4 constitutes a counter-argument. The Swing team knows that scrolling tabs is a crappy solution--they were leaned on to implement it. I know this because I talked to them and that's what they said. * What's needed instead is a drop down list (AKA readonly combo box) in place of the sideways spinner. One click to drop it down, and one click to select the tab. With most of the screen real-estate available (notebook tabs tend to be near the edge of the screen) the drop down list can be long enough to display all of the tabs in the majority of cases. Comments?
I agree totally. The tab management and sizing is problematic with many files, and a drop down would be much better. To avoid this, you can use the editor switcher (Ctrl+F6).
Completely agree. When many editors are open, scrolling tabs are worthless for navigation. A dropdown combo box would be faster than navigating with the Ctrl-W dialog, (in most cases) the Packages or Navigation views or the browser, and would use no more screen real estate than the current sideways spinner. The dropdown should be available even when no tabs are hidden, so as not to force the user into different, dynamically changing navigation modes.
Did you guys look into the existing Ctrl-Shift-W "Switch to Editor" dialog? That is definetely very usable, with sorting and all ...
Ctrl-W ("Switch to Editor") is cool. However, the UI designer decided to offer a widget for tab navigation, in addition to Ctrl-W--the sideways spinner. I think that was a good decision. Given that, I think you can still argue for a "better sideways spinner"--the drop down list, or some other, better idea. Perhaps a button that displays the "Switch to Editor" dialog. Hey, what a concept...
I think the dropdown would be faster, but Ctrl-W Switch To Editor is pretty good and can be used entirely from the keyboard. However, there has been talk of removing this dialog, apparently on the advice of "usability" people. Maybe both is overkill, maybe not, but it would be awful to wind up with neither.
I'd also suggest that there should be some (optional) reordering of the tabs, with the most recently used tab placed at the far left. This would allow someone to very quickly and easily switch between the current tab and the last used tab.
+1
So when you click on a tab it jumps to the left? This would be pretty surprising behaviour. I could picture a scenario where the tabs show only the most recently used N items, with new items appearing at the right. So frequently used but long lived editors would tend to migrate to the left. However, we will not be doing anything this funky for 2.0. This would also require a mechanism for showing all editors (e.g. the editors dialog, or a drop-down).
No, you're right, clicking on a tab and having it jump to the far left *would* be pretty surprising behaviour, and entirely undersirable. Having the tabs move around is pretty surprising, but there has to be some way of making the most recently or most often used tabs more easily available to the user. What do you think of moving the tabs only if they were picked off of the <alternate-tab-choosing widget>? That way if they click on the tab itself, it stays there... The whole problem with this is that it requires the GUI to choose for the user what the correct order of tabs is, and that's Not Good (tm). How about draggable tabs? They can be dragged around to change order? (This doesn't replace the idea of a drop-down...)
Oops, my bad. Tabs already are draggable...
"tabs show only the most recently used N items" sounds about right. "This would also require a mechanism for showing all editors (e.g. the editors dialog, or a drop-down)" Gosh, did we lose the editor dialog?
Eclipse 20021213 I believe the new editor management addresses all the issues in the bug report. An optional pull-down is provided on the tab folder (window>preferences>workbench>editors>show editors pull-down). This same editors list is also activated by ctrl-shift-w. In addition there is a view (window>show views>other>basic>editors) which presents the same information. The list of editors can be sorted by MRU, or alphabetically. Tabs are not re- ordered based on the presentation of the editors in the drop-down or the view. Finally you can change the amount of compression you see in the tabs via the same preference referenced above. Marking the bug as fixed. Please re-open if I am mistaken, stating what additional functionality is required. Report new bugs with the new editor management in a new bug, that way they don't get lost.
The dropdown is nice, but the sideways spinner is back in M4. For the reasons I originally stated, the sideways spinner is wrong here. Combining it with the dropdown seems like a wrongheaded compromise.
What I'd like to see here is the option of showing multiple rows of tabs (wrapping tab layout) so that all the editors can be viewed at once. For many of us, the loss of screen real estate is well worth it. Unfortunately, SWT's wrapping tab layout does row shifting (which is the topic for another report), but it would still be great to have this option.
(M5 continues the sideways-spinner...) In retrospect, using notebook tabs to display a dynamic, variable-length list of variable-length items is just wrong. That's why we're hacking away with dropdowns, sideways-spinners, "editor tab compression settings" and ctrl-shift-W's--the notebook metaphor is wrong for the task. We need a whole new approach to (or elimination of-) editor pane reuse, and the notebook metaphor needs to go. Does anyone else see it this way?
I'm using 2.1.1 and haven't found the dropdown or new views for editor management (both of which I think are good ideas). The original problem stated in this report had to do with the number of clicks needed on the spinner to navigate tabs. Visual Studio .NET has the same spinner on the right but treats the tabs as a "tape" that scrolls as long as you hold down the arrow. This is much faster than one click per tab and may be a suitable change in behavior of Eclipse's spinner. Maybe the last post is right and a new editor metaphor is needed. Personally, all of the available options work for me: Ctrl+Shift+W, Ctrl+F6, modified scrolling spinner button, editor dropdown list, and editor view.
Has anyone looked at IntelliJ's tab management? They have the option of having multiple rows of tabs for open files. Frankly, this is the most useable solution I have come across and I really wish Eclipse would support this feature. I'd gladly sacrifice 3 or 4 rows of vertical space to tabs.
fixed in 3.0
