Skip to content
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

Closed
stefcameron opened this issue Nov 5, 2016 · 37 comments · Fixed by #39176
Closed

Allow to shrink tabs instead of keeping a minimum width #15048

stefcameron opened this issue Nov 5, 2016 · 37 comments · Fixed by #39176
Assignees
Labels
feature-request Request for new features or functionality on-testplan workbench-tabs VS Code editor tab issues
Milestone

Comments

@stefcameron
Copy link

  • VSCode Version: 1.7.1
  • OS Version: OSX 10.11.6, Windows 10

Steps to Reproduce:

  1. Open many files in the same editor until there are more tabs (per file) than can fit in the editor's tabbar real estate.

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.

@stefcameron stefcameron changed the title Workbench should allow tabs to be compressed to prevent scrolling tabbar Workbench should allow editor tab width to shrink to prevent scrolling tabbar Nov 5, 2016
@stefcameron
Copy link
Author

stefcameron commented Nov 5, 2016

FYI, I'm not sure if this feature request is a duplicate of issue #7987. A comment by @rocksthehouse is the same thing, but seems like an issue in another issue...

@bgse
Copy link
Contributor

bgse commented Nov 5, 2016

@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.

@stefcameron
Copy link
Author

@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:

  • add a setting option to not show the icon theme in the tabs (only in the Explorer)
  • add a setting to control the font/size used for tab titles

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.

@bpasero bpasero changed the title Workbench should allow editor tab width to shrink to prevent scrolling tabbar Allow to shrink tabs instead of keeping a minimum width Nov 7, 2016
@bpasero bpasero added feature-request Request for new features or functionality workbench workbench-tabs VS Code editor tab issues labels Nov 7, 2016
@bpasero bpasero removed their assignment Nov 7, 2016
@bpasero
Copy link
Member

bpasero commented Nov 7, 2016

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.

@zakdances
Copy link

There really should be an option to fit all tabs in one screen by truncating their names. It's how Sublime Text 3 works.

@thSteve
Copy link

thSteve commented May 26, 2017

+1

@RenaldasK
Copy link

RenaldasK commented Aug 1, 2017

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.

@jroboyd
Copy link

jroboyd commented Aug 21, 2017

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).

@CedricReichenbach
Copy link

CedricReichenbach commented Oct 9, 2017

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 shopping-cart-preview.component.html. Even a handful of those might already overflow on a customary HD screeen. In particular, the .component.html part is not super relevant and I don't need to see it at all times.

@CreepGin
Copy link

The tabs will be much more usable when implemented like the auto-width Chrome browser tabs.

@dkniffin
Copy link
Contributor

dkniffin commented Nov 2, 2017

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 cmd+shift+[ing since I usually prefer my keyboard) between them to find the one I'm looking for, but I'd like to see all of them.

@jamesgecko
Copy link

jamesgecko commented Nov 3, 2017

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.

screen shot 2017-11-03 at 11 30 37 am

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, numbers-bulk-edit-modal.html (6f2881^1) <-> (6f288114) I still wouldn't see all four tabs I currently have open in that editor group.

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.

@stefcameron
Copy link
Author

@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 rootFolder/dir0/.../dirN/filename, with more collapsing as the horizontal space reduces, such as rootFolder/.../filename, down to filename, would go a long way in improving usability.

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 dir2/.../myfile.js and dir5/.../myfile.js.

@rodriguezmanu
Copy link

+1

1 similar comment
@kllystvns
Copy link

+1

@bpasero
Copy link
Member

bpasero commented Nov 18, 2017

Would something like this work for people?

before

Behaviour:

  • active tab is always fully visible (this means even if it has a very long file name it would never shrink)
  • there is a minimum size of the tabs still at 60px to at least fit the icon (if any) or the first file name character
  • the close button is always visible
  • tabs shrink even across all and show a "..." once they are shrinked
  • the scrollbar still kicks in if needed

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.

@CedricReichenbach
Copy link

@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?

@jamesgecko
Copy link

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:

Multiple rows create jumping UI elements, which destroy spatial memory and thus make it impossible for users to remember which tabs they've already visited.

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 window.title setting shows it on the title bar right over the tab.

@bpasero
Copy link
Member

bpasero commented Nov 19, 2017

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).

@stefcameron
Copy link
Author

@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.

@owenisred
Copy link

@bpasero the mockup you made looks like a great improvement - really can't wait for something like that to be available!

@kevinmartinez
Copy link

Solution suggestion looks good. This is really needed. I have gotten disoriented quite a few times wondering where my tabs went.

@DavidBabel
Copy link

DavidBabel commented Nov 24, 2017

Yeah seems great ! Adding an option to let icons disapear if there is not enougth size could be a good approach too.

@bpasero
Copy link
Member

bpasero commented Nov 25, 2017

Another interesting question: Would people expect each tab to have the same width even if that means the label shows with a "..." although there would be enough space?

In other words: Chromes tab behaviour is very deterministic. Each tab always has the same width, no matter how much space the tabs container has.

To compare with VS Code:

Each tab having same width
image

Each tab fitting their content if space is available
image

Independent from the behaviour above, in both cases the tabs start to shrink evenly once space becomes little:

image

@stefcameron
Copy link
Author

@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.

bpasero added a commit that referenced this issue Nov 27, 2017

Unverified

This commit is not signed, but one or more authors requires that any commit attributed to them is signed.
@bpasero
Copy link
Member

bpasero commented Nov 27, 2017

Yeah I like to show the full contents of a tab if possible, so this is how it would work:

before

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.

@jamesgecko
Copy link

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?

@bpasero
Copy link
Member

bpasero commented Nov 27, 2017

@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.

@bpasero bpasero self-assigned this Nov 27, 2017
@bpasero bpasero added this to the November 2017 milestone Nov 27, 2017
bpasero added a commit that referenced this issue Nov 27, 2017

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
@bpasero
Copy link
Member

bpasero commented Nov 27, 2017

Pushed this (will be in tomorrows insider release). A new setting workbench.editor.tabSizing is added with values fit and shrink. Set it to shrink to get the behaviour as outlined in #15048 (comment)

@Tekbr
Copy link

Tekbr commented Nov 29, 2017

-- 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.

tab

@bpasero
Copy link
Member

bpasero commented Nov 30, 2017

@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:

before

I pushed that via d6cb7ab

bpasero added a commit that referenced this issue Nov 30, 2017

Unverified

This commit is not signed, but one or more authors requires that any commit attributed to them is signed.
@Tekbr
Copy link

Tekbr commented Nov 30, 2017

-- 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! 👍

@bpasero
Copy link
Member

bpasero commented Nov 30, 2017

Sure, feel free to create a new issue for it and we can ask for help.

@gnowland
Copy link

gnowland commented Jan 6, 2018

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!

@bpasero
Copy link
Member

bpasero commented Jan 6, 2018

@gnowland there is always a hover showing up for a tab after a moment with the full path, right?

@gnowland
Copy link

gnowland commented Jan 8, 2018

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.

@vscodebot vscodebot bot locked and limited conversation to collaborators Jan 11, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
feature-request Request for new features or functionality on-testplan workbench-tabs VS Code editor tab issues
Projects
None yet
Development

Successfully merging a pull request may close this issue.