Community
Participate
Working Groups
Three characteristics of the new view tabs eat up screen real estate without providing much value: * The view icon in the tab * The rounded tabs * space for close button in unselected tabs. I'd recommend following the Mozilla convention for the close button: right click on a tab does not change focus, but opens a context menu with options for 'close tab' and 'close other tabs'. I suspect that one of the motivations for the new tabs to indicate which tab is selected. I'd bet we can achieve this via color and/or some more subtle notation.
Created attachment 7951 [details] contrast old and new tabs
I'd agree with the idea of following the Mozilla convention re tabs, which is also the behaviour that Safari (MacOSX) follows. Safari tabs are emulated, work well, and are a UI convention Mac users are familer with. If Eclipse has to use an emulated tab, then perhaps an OSX-specific emulation that's closer to the Safari L&F would be possible? The new Eclipse L&F is terrible under OSX, to be honest. It's like using NetBeans, although slightly faster.
good comments, will investigate bill, could you drop in a snapshot of the Safari tabs here to document your comments p.s. are the you the Bill who grew up in the house next to mine in the tiny town of Lakeville NS<grin>?
added bill to the cc list
+1 if you do decide to get rid of the close box, why not just use the native platform tab implementation instead of the emulated ones? AFAIK the only reason we're using the emulated one is because someone somewhere wanted those floating close boxes on each tab. i would much rather see the native implementation anyway, even if it means losing the close button. here are a couple of suggestions to implement the same functionality using the native tab widget: * middle-clicking a tab closes the window. this is the way mozilla (with tab extensions) does it. i like this better, anyway, as i often accidently close a window when rapidly switching between tabs (i hava bad aim). this way there is no way that an errant left-click can close a window. also, the context menu is an option. * clicking on any portion of the tab bar that's not a tab or scroll button opens the list of available windows.
One thing I don't like about the new tabs is that they change their size depending on whether they are selected. That means that click targets are constantly moving around, which can be quite frustrating, especially with those tiny close hotspots. The content and thus the size and position of the tabs should not change depending on which tab is selected. (The other thing I don't like is the look, on neither Windows or Mac. But I'll leave that for later when I have constructive suggestions :-) ).
Created attachment 7967 [details] Tabs in Safari This screenshot shows tabs in Safari. These are tied to the metal-brush look on Mac OS X, and thus IMHO not a good fit for Eclipse. They would win an award in subtleness though.
Created attachment 7968 [details] Tabs in Camino Tabs in the Gecko-based Camino browser for Mac OS X. These are native tabs IIRC. As a Mac user, I'd also prefer native or at least native-looking tabs to both the old and (current) new Eclipse look. I don't see a real need for a close button on every tab either, that can be done via a context menu action when clicking on the tab, or a keyboard shortcut. The problem that remains is how to drag a view.
+1 for native looking tabs on all platforms +1 to keep the close buttons on tabs I'm sure there is a solution that keeps the close button I. NetBeans (possibly Swing?) demonstrates that this is possible (at least on their screenshots it looks native). It's a nice feature to close tabs with a single click. BTW, what PDF version is that? I cann't open them with Acrobat 5.0 on Windows.
Created attachment 7969 [details] Tabs in Safari (PNG format)
Created attachment 7970 [details] Tabs in Camino (PNG format)
Native looking tabs with close box can be rendered on Windows XP by using DrawThemeBackground() API call to render the tab and then just render the close box bitmap on top of it.
I think context menu with option to close the tab is much much better (by the way Visual Studio.NET has this on view and editor tabs). This will ONLY work if the X icon is removed altogether, since too often one inadvertently closes the view instead of switching to it. Also scrolling of editor tabs needs to be brought back. Again Visual Studio.NET does this very well. Little scroll arrows are always there, and enabled when editor tabs do not fit. The editor tab width is always large enough to fit the name of the file with extension and never shrunk if more tabs are added, but simply scroll arrows are enabled. The scrolling of tabs is done smoothly and speed of scrolling seems to increase the longer you hold the arrow pressed. I will try and attach a screenshot of VS.NET 2003..
Created attachment 7979 [details] Visual Studio.NET 2003 screenshot
I don't think that we need the left and right scroll for editor tabs. This is not very useful because you have to click it several times to find a tab. The drop-down list provides a better usability. BTW, I never saw Visual Studio before but it looks good (not perfect but good). I had a similar look for Eclipse in mind but it is interesting that my expectations of a native look for Eclipse are somewhat similar to the Visual Studio look.
Actually, the point with Visual Studio.NET is that you don't have to click the scroll arrows a few times. You click once and hold, while the tabs are scrolled very smoothly in the selected direction. The scrolling gets slightly faster if you hold the arrow button pressed longer. I find the drop down menu for editor tabs a bad idea, since the number of editor tabs can potentially get large. If I have gigabytes of memory and I choose so I can open 100 editors or more. In that case the drop down falls off the screen or needs to be scrolled itself. I find the arrows much more elegant solution.
Gunnar, I strongly believe that one of the reasons why Eclipse is so appealing to Windows users is that in seconds it can be personalized to look and feel almost exactly like Visual Studio, which is a very mature windows product. Microsoft does invest a lot in its UI design (they even videotape users in the "usability lab" working with their UIs and watch their face strain and then go back and try to improve it). It find it almost serendipitous that Eclipse looks like VS by accident if you will. I guess great minds think alike :). In any case I believe it it is Visual Studio that has to play a catch-up game to Eclipse for its other code browsing and refactoring features, but I'm getting seriously off topic...
+1 for the original posting. * Tab names should first be compressed (with ...) to gain more space and to avoid the cumbersome tabs menu.
Actually, by compressing the tab you are clipping the name of the file open in the editor. If the user has several files beginning with the same token (which is a very likely case actually), it is really hard to tell the editors appart. One has to wait for tooltip to appear to be able to tell which file is actually open in the editor. Again, this could be a user preference, but the default should be not to clip.
Created attachment 8070 [details] Editor Tabs Clipping Example of editor tab clipping. Which file do I want??
I have added an illustration (in the attachment) that shows why editor tabs clipping is bad. This is a screenshot of the actual source that I work on. I did not come up with the names, but I have to work with them :) It is difficult to tell editors appart on first glance, which reduces usability...
Note that this scope of this bug report is *view* tabs, though it *may* have implications for editors as well.
Mario: Your screenshot shows nothing to me. With unclipped tab names, you would only see 2 tabs at any time -- which won't help you much. Anyway, my argument was mainly for view tabs (see bug's subject), where I hope your environment has more varied names.
Right now Editor and View tabs look and behave exactly the same, hence I did not make distinction between them. If we are talking about view tabs only, then clipping them is an option. However, in that case close button definitely does not belong on them.
I don't want to mark this as fixed as it mentions other things but I have removed the close "X" from unselected view tabs.
Related to bug 52685 (and older bug 37997).
Comments re: Integration Build 0226: - Right clicking on a view tab for a view which is currently out of focus should not bring the view to the foreground, but should display a context menu that allows me to close the view, or all of the others (in which case the focus would change).
I have released a first step in adding support for tabs that are less rounded, the next step will be to add shortening of the text to use less space. Please try it out Window > Preferences > Workbench > Appearance > "Show traditional style tabs"
marking as fixed. This bug originally reports three things: * The view icon in the tab * The rounded tabs * space for close button in unselected tabs. - icons are only shown in the active/selected tab now, this can not be removed as there is API to set the icon and some views use this to show state - options available for non-rounded tabs (Window > preferences > workbench > appearence > show traditional style tabs - no close button on unselected tabs -
But what about the "close other tabs" option to allow users to close all but the current editor tab. I find it very useful...
What I understood was that there was a suggestion to have right click on a tab not change focus but open the view tab menu (with whatever contents.. including close). If you think close others would be interesting on views please log a bug for that.
