Community
Participate
Working Groups
Make the filename tabs smaller (start by removing the icon!), and allow for stacking them in 2 or more tabs rows. Filename should never be truncated, and it should easily support 20 files without UI-pain...
Even better, make it possible for them to run down the side of the window - much easier to comprehend (especially when sorted alphabetically) and lets you get many more on screen at a time.
There are many PR about editor managment and tab sizes. I will increase the priority of this one so we can close it whenever we close/fix the others.
The following bugs are all related to the same issue: Bug 20626 Bug 21968 Bug 22716 Bug 25165 Can the priority of this issue be increased?
Eclispe 20021203 and beyond has new editor management behaviour. One of the preferences on the editor page (window>preferences>workbench>editors is to set the amount of compression for the tabs. The default is high, which was the current behaviour at the time of the feature introduction. With the addition of the pulldown button, do you still see a requirement for multiple lines of tabs? This would take additional space away from the viewable area. One other feature introduced was an editor view (window>show view>other>basic>editors. Ability to sort the editors by Name or MRU is supported on both the view and the new pulldown. Again, with this new functionality do you still see a need for multiple lines of tabs, or even tabs going vertical rather than horizontal.
I agree that multiple rows may not be needed. But I think that the tabs row -could be much thinner (2/3 of current height, that would allow for 2 rows max without disturbing the space) -and use a even smaller font, -without left icon -without the X right icon space unused (it should only overlay the name but not occupy space when not highlighted) This way you could easily fit 15 filenames on a single row of around 900 pixel wide.
If we removed the left icon, we would loose the view pane menu.
*** Bug 29888 has been marked as a duplicate of this bug. ***
in my view these points are important: # Filename should never be truncated # multiple rows # no icons # no "X" in addition the priority is in my view higher than "p3", the way it works at the moment is not very convienient !
There are no plans for the UI team to work on this defect until higher priority items are addressed.
Commnet #4 mentions that "Eclispe 20021203 and beyond has new editor management behaviour. One of the preferences on the editor page (window>preferences>workbench>editors is to set the amount of compression for the tabs." I'm working with build 200303272130, and this option is just not there. It was there in one of the earlier builds, but was removed, for some reason. I think that it is an important feature.
*** Bug 27592 has been marked as a duplicate of this bug. ***
In recent 3.1 integration builds, you can specify org.eclipse.ui/EDITOR_MINIMUM_CHARACTERS=<N> in "<install>/plugins/org.eclipse.core_3.1.0/plugin_customization.ini". <N> is the number of characters that must be displayed for each tab. Setting this to a large number (e.g., 1000) effectively disables tab compression.
Please see Bug 28722 for the request to stack them in multiple rows. Any comments about multiple rows should be appended there. This bug will only deal with the issue of improving control of truncation (or to get rid of it entirely).
Actually, as the reporter, I didn't mean anything related to truncation. And I don't want truncation at all. Yet I don't want to scroll either, like in current 3.0 and above. The left side document selector of text pad is the most efficient approach, although it wastes significant space. The ultimate domument selector, is one with small but readeable font, no icons, and that goes 45 degrees angle text tabs when there is enough tabs to justify it. You can stuff a good 20 file without scrolling with 45 degrees tabs.
And if you can offer an autosort by name, just like textpad document selector, you solve a big problem with document tab searching.
*** Bug 61060 has been marked as a duplicate of this bug. ***
*** Bug 61497 has been marked as a duplicate of this bug. ***
Actually, I can imagine the angle of tabs starting from 0, when all fits, and raising slowly as new documents are added, until 45 degrees, (or more, until annoyingly too steep).
If you want tabs on the left or right, please see Bug 21968. This bug is being left for the original request of trying to minimize space used in the tab.
Thanks for pointing rfe #21968. The font is a major factor here: as small as readeable (should be configurable more directly than through global/basic font setup). As for angled tabs: here is some observations: -requires lightweight component, a dedicated tab panel widget, since hovering/clicking will occur in non-rectangular zones -although having only one angle (ex: 45 degres) could be simpler to implements, it will waste vertical space faster if names are long but few. -as soon as angled tabs starts, the bar height doubles (last char of previous name above first char of next name). It would look funny/wastefull if only few chars were overlapping. So I suppose a minimum angle is also required (20 degres?)
For the record I would like to refer to a screenshot of bug #61497 that was closed as duplicate: https://bugs.eclipse.org/bugs/attachment.cgi?id=10421&action=view Genady
*** Bug 107216 has been marked as a duplicate of this bug. ***
Regarding comment #12, in 3.1 the ini file now seems to be located here: <install>/plugins/org.eclipse.platform_3.1.1/plugin_customization.ini
Moving Dougs bugs
As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009
I don't think this will be done in 3.x. e4 / Eclipse 4.0 will allow modifications like this, but don't expect that the Platform UI team will implement the particular tab look and feel described in this bug. Rather, it will be possible to replace parts of Eclipse (like the tab rendering) with your own. Feel free to participate in http://wiki.eclipse.org/e4 if you are interested.
