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

Option to display Tab Close Button only on the active tab, and to avoid hiding it on hover #100782

Closed
scscgit opened this issue Jun 22, 2020 · 3 comments
Labels
feature-request Request for new features or functionality workbench-tabs VS Code editor tab issues

Comments

@scscgit
Copy link

scscgit commented Jun 22, 2020

The setting [Workbench > Editor: Tab Close Button] (workbench.editor.tabCloseButton) currently supports 3 options: [left, right, off].

My suggestion is that the most logical option is currently missing, even more so considering the current auto-hiding behaviour of the close buttons when the [left] or [right] is selected; specifically that there should be an option to disable (hide) the X buttons on all inactive tabs. Personally I don't ever see a need to close a tab via left-click if it's not a current tab, as I want to avoid the possibility of closing it by misclick at any cost (both in browsers and IDEs), so when I want to close a tab, I prefer to click to open it first, so that I'm sure about what I'm closing. Just like in browsers, there's always the alternative to close tabs quickly using middle-click, which power-users often prefer, as it more closely represents the intention of closing a tab (without any "confirmation") instead of switching it (and doesn't require precisely aiming when you do it in bulk); so if one is sure, they aren't forced to click twice. However, I still think that it's wrong to be being forced to choose the [off] option, always use middle-click, and lose the option of making sure that I always close only the tab which I intended to close. (And there's no other reasonable left-click interaction with the current tab.)

On top of that, with the auto-hide behaviour enabled, there's the constant risk of user trying to quickly switch tabs and forgetting to calculate and predict the exact position and size (and existence) of the hidden X button in their mind, and I personally wouldn't ever accept such a "visual decluttering" UX design compromise if I had the choice, as it makes the workflow error-prone for literally no reason (there's no gain in tab size), creating the (routinely occurring) possibility of closing a tab in the worst case without even noticing. (By the way, note how my solution would seamlessly remove the need of a workaround like hiding anything while not hovered over.)

  • I'm not sure if the behaviour of "hiding the X buttons when the user doesn't hover over them" is a recent change, as there was an issue asking for it (Editor: Tab Close Button.. Please add Hover #88253) without any response, but I don't see any way to out-out of this user-unfriendly decision.

For this reason, if it were possible to remove the X button from all tabs other than the active one, I would suggest that the X button should be always visible. It's the tab that's already open, so there's no harm in hiding a part of the file name (which is already displayed in the window title anyway, along with breadcrumbs, the explorer, and even the tooltip - is that still not enough?). On the other hand, when I'm looking for a tab to switch to (and I have tabs configured to shrink, as scaling them based on file name is nonsense if barely 4 tabs fit on one screen), the hovered one I'm focusing on the most is always covered by the X button, reducing effectively visible name by 40%, thus constantly forcing the cursor to move away before returning back.

  • To add a few other notes; if the user doesn't know about the CTRL+SHIFT+T key, there isn't even any user-friendly option to Reopen (Last) Closed Editor (Tab) via right-click, so an inexperienced user may have to install the "Reopen Closed Tab" extension. (Btw. some arbitrary tabs cannot even be reopened, e.g. Settings.) The misclick probability is even higher due to the fact that the "buttons in the editor title bar - the ones near the Split Editor button", whatever they are called, completely change when you click on different file types, which includes random changes for every extension you have, e.g. Add option to hide editor title buttons gitkraken/vscode-gitlens#540, which moves all of your tabs after an arbitrary delay, of course changing all of the X button placements. These buttons cannot be configured globally whatsoever, as you have to research every single extension's documentation and hope that they expose the functionality to disable them. The buttons don't support any intuitive right-click configuration (like how you would hide the extensions in your browser), and they cannot be moved away, e.g. below the tabs, so your effective tab area is arbitrarily reduced both from left and right sides, as if tabs were some completely insignificant feature (along with the decision of your "designers" that denying multi-row tabs will make the product better). Another example of how misclicks easily occur is Allow to close multiple tabs without moving the mouse after closing one #40290. I'll add one more unrelated note in case this gains some visibility, as it can have a direct impact even on how this "optional setting" is named: please try to also consolidate the names or descriptions of settings like workbench.editor.limit.value (which finally replace the need for zentabs extension), as it's impossible to find or understand the meaning of this description when searching in settings for keywords like "tab/tabs" (I have no idea where people could learn that "editor" means "tab", and even if they try to clear the search textbox so they can look at the other nearby settings, they just get thrown back to the beginning of settings, right under the "Commonly Used" header).

All I'm asking for is an optional setting that covers this use-case even if it requires some workaround; though I'd be also curious to hear the opinion of (experienced and productive) developers (who use IDEs) regarding which defaults should be preferable :)

@bpasero bpasero added feature-request Request for new features or functionality workbench-tabs VS Code editor tab issues labels Jun 23, 2020
@bpasero bpasero removed their assignment Jun 23, 2020
@github-actions github-actions bot locked and limited conversation to collaborators Oct 8, 2020
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 workbench-tabs VS Code editor tab issues
Projects
None yet
Development

No branches or pull requests

3 participants
@bpasero @scscgit and others