-
Notifications
You must be signed in to change notification settings - Fork 29.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow to shrink tabs instead of keeping a minimum width #15048
Comments
@stefcameron Excuse me for giving the advocatus diaboli here, but what would shrinking the tabs really accomplish here? At best, we'd be able to fit a couple more tabs in there before we need a scrollbar anyway, and before we needed the scrollbar, we'd have introduced a negative effect on user experience since we'll end up with tabs that have half the information we need (often times the relevant information is at the end of filename) and get harder and harder to read the more tabs we add, or no information at all and just anonymous tabs we can click through one by one (when there is just the X left). Scrolling on the other hand works very natural and fluid with mouse, trackpad (and possibly touchscreen, have not tried it), even with a huge number of tabs. Compression to the minimum required space (for the individual tab) would probably make room for one or two extra tabs before overflow starts, but then again having a uniform width makes for good usability and less UI noise. All imho, not against the idea in general, just trying to get some discussion going. |
@bgse I appreciate the discussion. :) You do make some good points, however I use a Wacom tablet and horizontal scrolling in those tabs is really annoying with that tool... It's very awkward at best. I my mind, having to scroll the tabs is a negative effect on my user experience. I'd prefer it the other way (compress, and never scroll). But I fully recognize others would see it the other way around, hence my suggestion to allow this to be configured. So I'm coming from Sublime, trying to give Code a good try. Sublime does this type of "compression" I'm asking for here and I find it works really well. I rarely end-up in a situation where I have so many tabs open I can't recognize them by the beginning of the file names (or just positionally, from muscle memory). It literally took me all but 1 minute after opening Code for the very first time to run into this horizontal tab scrolling scenario within an editor (which was hard to discover; at first I had no clue where my tabs went) with barely any files open. Note that I work on a 2560x1440 monitor and always split the layout to 3 vertical editors so I can see and work on 3 files at a time, so that makes the editors narrower. Of course, having so many tabs open in a single editor that they are reduced to just the close (X) button isn't usable, and I tend to close tabs before it gets to that point (talking from a Sublime perspective). Right now, I'm discovering some keyboard shortcuts in Code that are making things tolerable, but still not as easy as clicking directly on a tab I know I want, or in the extreme case (in Sublime), positioning my cursor over a tab long enough for a tooltip to show me the full file name. One key difference between Sublime's tabs and Code's tabs is that Sublime attributes equal width to all tabs (to a maximum) within its equivalent of an editor window, whereas Code gives a tab the width necessary to show the entire file name. Depending on the project, Code's editors can therefore very quickly run out of horizontal tab space. Now suppose this feature request isn't implemented. Other things that could help would be:
Both those settings could help reduce the overall width necessary to display a tab and allow more of them to be displayed before the scrolling becomes necessary. |
We made the explicit decision to never shrink tabs smaller than their file name. It is unlikely that we will change this or add an option, but leaving this open for the good discussion in here. |
There really should be an option to fit all tabs in one screen by truncating their names. It's how Sublime Text 3 works. |
+1 |
I had no idea that I can scroll the tabs with mouse wheel until I came across this ticket! And even now that I now that, I still find myself not using it and instead close some tabs to fit. In my opinion the usability of editor tabs would be MUCH better if users could choose to shrink and fit all tabs. |
Please make this a configurable option. Really annoying coming from sublime text not being able to see all the tabs open with a split screen configuration an no side bar. And from a design point of view, it is a really common design pattern to condense tab widths, look at chrome, internet explorer, edge (combines elements of both). |
Being able to truncate file names would be especially helpful when working with long-named files. For example, an Angular project following the convention of suffixing filenames with their respective type may contain files like |
The tabs will be much more usable when implemented like the auto-width Chrome browser tabs. |
I just switched to VS Code from Atom, and this is probably the single most annoying "feature" of VsCode. I always have lots of tabs open (as most of us do), and scrolling through them is giant pain for me. Forcing all the tabs to be full-width is very inconsistent with any tab experience I've seen. Chrome, Firefox, Safari, Atom, and Sublime all do some form of tab shrinking. Even if it doesn't show the whole name of the tab, having an icon and/or just a few characters showing is often enough for me to know which one it is I'm looking for. In the case where it's not enough info, I'm fine clicking (or |
This frustrates me constantly when using three vertical editor groups, particularly with files that have long names, or when using Git Lens's stash view. I have vscode full screen, and that's the entirety of an editor group tab area devoted to a single buffer. Obviously Git Lens could use a shorter name for the buffer, but even with a shorter title like, There's plenty of space for the full title of the file in the window title bar (or the status bar, with an extension). A partial name in the tab bar is fine for switching between buffers. |
@jamesgecko Exactly my point from long ago! Thanks for putting a picture to it. I'll say it again: IMO, the most important parts of the file path are the beginning and the end. A strategy that collapses the middle of the path, such as One exception to the collapsing, of course, might be that the smallest unique path is retained in the tab if there are multiple files open with the same name (even across editor groups, IMO). That could mean something like |
+1 |
1 similar comment
+1 |
Would something like this work for people? Behaviour:
PS: we had a bug in the tabs control where on touch devices it was not possible to touch using the finger, we fixed this in 1.18. |
@bpasero Looks nice! I think that's a pretty good solution, just one detail: The never-shrinking active tab causes tabs to "jump around" when switching, which might cause slight disorientation. Seeing the current file name in full is probably not always crucial either, so maybe make it configurable too? |
I've never seen tabs resize like that, so I went looking for UX research about it. Point 10 in this Nielsen Norman Group article is the closest thing I've found:
That's about multiple rows of tabs instead of tabs that resize, but it still seems to echo @CedricReichenbach's concern about disorientation. It also doesn't improve my use case, where I'm often working with many files that have long names. I don't understand why showing the full name of the active tab on the tab is such a large concern; the default |
Yeah I get the point about making it hard to keep a memory of which tab is where if the active one is always pushing the others away. I guess we could just say that a tab will never change its size even if being active. Basically this would go into a direction of Chromes tab model where each tab gets small enough until only the close button is visible, but you would never get a scrollbar and each tab always has the same width. Since I find that a bit odd too, I would have a minimum width for tabs (we could also think about hiding the icon once the space is too little). |
@bpasero Thank you for the mockup, and the work that has already gone into making it possible! I think this is a great start toward making lots of tabs more usable, except for the point about the active tab always having its full title visible. I don't see how that would solve the issue @jamesgecko previously raised on this topic. It seems like keeping the full title of the active tab always visible would defeat the whole purpose of shrinking tabs -- which, in my mind, is to eliminate (as much as feasible) the need to scroll the tab bar (very tedious with a Wacom tablet) and the loss of my ability to visually locate a file just by the fact that I've learned where it's located in the tab bar (even if I can't see its name because only the icon is visible) within an editor group. |
@bpasero the mockup you made looks like a great improvement - really can't wait for something like that to be available! |
Solution suggestion looks good. This is really needed. I have gotten disoriented quite a few times wondering where my tabs went. |
Yeah seems great ! Adding an option to let icons disapear if there is not enougth size could be a good approach too. |
@bpasero I would expect each tab to fit its content. As the window narrows, the wider tabs should start to shrink before the tab with the shortest title. Once all other longer tabs are now the same width as the tab with the shortest title, all tabs should start to narrow evenly. The ellipsis takes quite a bit of room. I like how Chrome tabs slightly fade the title away at the edge where it's being cut off. IMO, that leaves a bit more width where an extract character or two, depending on character width, might still fit. |
Yeah I like to show the full contents of a tab if possible, so this is how it would work: I cannot control how much space the "..." takes because the clipping is done by CSS. I would have to do my own custom overflow behaviour otherwise if I wanted to show less. But we can always tweak that in the future. |
Looks good! Question: if you have two editor groups of equal size, they do not have the same amount of space in the tab bar visible; the diff/split/... buttons appear at the right side on the active tab bar. How will this interact with that? Do all the tabs resize when the active editor group changes? Will each inactive editor group tab bar reserve an empty place for those buttons? |
@jamesgecko the behaviour of the editor actions tool bar is not changing in any way. Actions appear and hide very dynamically as before and the tabs will adjust to that change. |
Pushed this (will be in tomorrows insider release). A new setting |
-- Sorry for the English, I used Google Translator -- @bpasero An idea ... Instead of using the '...', why not use the style of Microsoft Edge, Mozilla Firefox and Google Chrome? 😉 The text is below the "X" (erased slightly) as the guide decreases. Particularly, I prefer the style of Firefox. |
@Tekbr good suggestions. I am not a big fan of how Edge is simply clipping the text at the end of the tab. I really like what Firefox/Chrome are doing with the fading out in the end, if anyone wants to chime in with a reasonable PR (not too crazy, just CSS), feel free. What I can change though is to not leave the room for the close button. I realized that when shrinking is enabled, the close button should only show up on hover, but otherwise not consume any space: I pushed that via d6cb7ab |
-- Sorry for the English, I used Google Translator -- @bpasero Thanks for the feedback!! I was happy with your move !! 😄 👏 👏 By your comment it seems like something simple to do (or not) 🤔 , but after going through the team tests .. or even before (if you think better) maybe crawl for a new case suggesting for beginners, no? Referring to this case and the test case, with my comment and your comment (if you think you should). That way, someone can locate it more easily! 🤔 Anyway, thanks again for the feedback! 👍 |
Sure, feel free to create a new issue for it and we can ask for help. |
Not sure if I should open a new issue for this, but would it be possible to show the full tab on mouse-over (hover) of an individual tab while keeping the others shrinked? I love the condensed "shrink" view but I've hit a problem when in some projects I can't see but a couple letters of a filename and multiple files start with the same letter! Showing just the hovered tab full-width would allow users to quickly scan over the tabs and switch to the desired one lightning-fast. Salud! |
@gnowland there is always a hover showing up for a tab after a moment with the full path, right? |
Full path hover? Yes. But that's hardly decent ux. I've never developed for vscode before but I'll take a crack at a PR as an example of what I have in mind. |
Steps to Reproduce:
Once filled, the tabbar enables horizontal scrolling to see hidden tabs to the left/right. That's really not user friendly... and it's especially frustrating when splitting the main window into 3 editors, and then opening multiple files in each editor.
I think having a workbench setting to choose between this scroll-based tabbar behavior and a new behavior where the tabs would "compress" (i.e. begin to reduce the horizontal width of all tabs in the related editor such that less of the file's name is visible in each tab until only the close "x" button is visible per tab) would be a welcome addition to tab management.
The text was updated successfully, but these errors were encountered: