You can see it like that. The difference is that in the explorer bar you can't choose how many there are. It's just a list of all files.
Personally I like it better if I open the files I currently need to work with, and they're all grouped as open tabs.
Also, not everything is a file. Tabs should apply to all edges of all windows, including top level windows, not just one edge of only windows with files in them. And you should be able to drag any window out to top level and it still has its tab attached, then move it around to any position along any edge, or hide it, and of course snap windows together along their tabbed edges, either tiling or overlapping.
How do you control all of that? That's where the pie menus on the tabs come in, of course. Thanks to the tabs, you can even pop up pie menus on windows that are completely covered up, and perform commands on them even though they're not visible, like bringing them to the top (stroke up) or down (stroke down), or closing them (diagonal stroke for confirmation submenu, then stroke up to confirm), or whatever (paste into terminal emulator, evaluate code in editor, etc).
It does, but it also limits the "open editors" list to a smallish size that makes it annoying to use when you have a lot of open files, and you can't resize it either.
I never knew you could drag the open editors list off to its own thing though.
workbench.editor.limit.value to change the limit, and workbench.editor.limit.perEditorGroup to change whether the limit applies to each editor group, or the total amount
I've been implementing and using vertical tabs since around 1988, with I released a commercial product with tabbed windows, the NeWS version of UniPress Emacs, and used it to develop a hypermedia authoring environment for HyperTIES at the UMD Human Computer Interaction Lab.
Vertically tabbed windows combine synergistically well with pie menus, and are great for window management, especially when you have many windows.
They are purposefully NOT patented, since the idea is so fucking obvious, but it's disappointing they took so many decades to catch on finally. Still there aren't any decent desktop window managers I know of that implement tabs the right way. (tvtwm is not the right way!)
The later NeWS Toolkit versions from the early 1990's let you drag the tabs around to any side of the window you like: left, right, top or bottom, to any position along any edge. The user should be able to decide which edge and where the tabs are attached to for each window, it should not be hard wired like the tabs in VSCode and web browsers typically are. Being able to choose which edge the tab is on and where the tab is gives users better more flexible ways to organize and manipulate their windows.
I had a video of the NeWS tabbed windows, demonstrating dragging the tabs to different window edges, but youtube took it down because it contained copyrighted music (Herbie Hancock's Rockit).
Oh, here's the original video you can download from my server:
Here's another NeWS program that uses vertical (by default, but any edge if you want) tabs on windows around PostScript objects that you can push and pop on the stack with "direct stack manipulation":
The Shape of PSIBER Space: PostScript Interactive Bug Eradication Routines — October 1989
This is a long-standing feature request that has not made any progress nor can I tell that there is a plan to work on this at all in the near future: https://github.com/microsoft/vscode/issues/108264
99% of the time I'm with 2 side-by-side editor panes open, so horizontal estate is very precious in this case, otherwise both documents won't fit well.
That's also why I'm thankful when people don't assume 16:9 screen estate and configure their max line length to huge amounts like 120 or more! 80, 100 max, is still today the sweet spot. But I digress.
For an IDE I wouldn't use vertical tabs on a side. But for web browsing they've become second nature to me, and Tree Style Tab for Firefox [1] changed the way I use the browser!
This is why you should be able to choose which side and position any tab is positioned along any window at any time, and change them at any time by dragging them to where you want.
Then you can assign meanings to each side, depending on your workflow, for example (this should be under user control, not set in stone, of course):
Tabs on the top for important stuff.
Tabs on the bottom for administrative stuff.
Tabs on left for things you haven't read yet.
Tabs on right for things you've already read.
Then drag the tab from the left to the right after you read something (like moving it from your "in box" to your "out box"), or pin its tab on the top or bottom of it's important and you want to keep it around and easy to find.
And if you really want, you should be able to hide the tab to save space.
And not only tabs for apps like browser and IDEs, but also the desktop window manager should support tabs on top level windows in a consistent manner, so you can drag tabbed windows in and out of other window frames, as well as arranging them in hierarchical outlines along the edges.
All this is super obvious, and saves a lot of time and effort, so it bewilders me why tabs like I described and implemented in the 1980's aren't universally supported on all desktops and applications by now.
It's not because they're patented. Adobe tried, and sued Macromedia over it, but that patent (illegitimate in my view, since it ignored the prior art, and was extremely obvious and not patentable) has long since expired.
I think one reason might be something similar (just in spirit, not the concrete concept itself) of another good idea killed by patents, in a whole different domain that was talked about in HN some days ago: mini-games that would appear during the loading screens of the actual game on a console. Bandai-Namco had a patent for that, thus it killed spread in other games.
Maybe both these are cases of good ideas that were there at the right time and place, but lost steam because of patents, and then later the timing was just too late already.
In the case of games, loading screens are nowhere as lengthy as they were when the mini game idea would have been useful. Similarly, the all-tabs paradigm would nowadays be way out of scope for commercial desktop environment makers, who are deeply immersed in a crusade to make simpler and mobile-compatible UIs for their systems, and have been so, slowly but surely, for at least the last decade.
EDIT: albeit if the idea had been around since the 80's, then my reasoning doesn't hold water! 90's was the age of multi-document UIs on Windows, and I'd argue that was the best time the idea had to get some implementations, but I guess it didn't get too much popularity back then either, or maybe Microsoft evaluated and didn't bet on it.
I used to set max line length on my projects to 120. However, I now live off-grid and primarily work from my 14” MBP. At this level, 80-100 really is the sweet spot, particularly with side-by-side or just a couple levels of sidebar.
I think Arc is the first browser I’ve seen to not offer it as a toggle, but instead make it the default and only option and to design the rest of the UI around it. Wouldn’t be surprised if for many people Arc is the first time they’ve encountered vertical tabs as a feature.
After reading the title and the first two sentences ("Vertical tabs in Visual Studio Code" and "I love vertical tabs. I use them wherever possible."), I first thought that the author loves using the vertical tab ASCII/Unicode character (U+000B, in C/POSIX: '\v') in his code, since I can easily imagine that Visual Studio Code has difficulties handling this character (I did not test it, though).
Not sure why though, is there something with the way it’s phrased that makes us think of the tab character? It’s not particularly ambiguous and I’m very aware that vertical tabs (not the character) exist so I have no idea why I first thought of the obscure vertical tab character
> Not sure why though, is there something with the way it’s phrased that makes us think of the tab character?
For me, a reason might be that I am not a native English speaker.
The "tab" meaning of the character, key, and typewriter mechanism is quite similar in German as in English ("[der] Tabulator" as the encompassing term, and specifically "[das] Tabulatorzeichen" (the character), "[die] Tabulatortaste" (the key), and "[der] Tabulatormechanismus" (the mechanism on a typewriter)).
On the other hand, the term for the GUI elements (derived from the office stationery) is quite different in German: "[der] Registerreiter" (for the GUI element that you click on to switch between tabs) and "[die] Registerkarte" (the content of a tab (tab page)).
While I know all the listed meanings of the English word "tab", the meaning of the first concept is the much more "natural" one for me.
Fun fact: at the beginning of its existence, VSCode didn’t have horizontal tabs, and the creators were pretty opposed to it. So at first, we had to deal with the « open editors » vertical system. Them adding support for horizontal tabs was a pivot moment that boosted VSCode´s popularity.
I just can't get my head around the mentality of making that decision for all of the users, hard coding it, and forcing it on them, not allowing you to choose for every window, or change your mind at any time, and simply drag any tab to any edge you want, whenever you want.
What makes user interface designers so arrogant and sure of themselves and lazy that they think one particular side is the only side, and the best for everyone, no matter what your screen size, resolution, aspect ratio, layout, number of tabs, icon or label size, workflow, direction of text flow, handedness, visual acuity, physical dexterity, task, and preference?
And then when you inevitably run out of space for tabs along the one edge, instead of simply allowing you to put more tabs along the other edges, you either add more horizontal rows along the top, so you get this abomination [1], or you have tiny little hard to use scrolling arrows at each edge so you can't see all the tabs at once, so you get that abomination [2]:
In ages past on smaller screens I would code on the left, then have some supporting docs open on either a tab or a right-hand screen.
But these days on my Dell 32" coding on the far left isn't that great, you actually have to turn your head.
I now split off a little left handed tab which I use to edit headers in code, for example includes, constants, enums, structs, variables and so on. Then just left of my natural forward eye position I have another tab for the rest of the screen and the code.
And as long as you can have tabs on any side of a window, how about multiple tabs on the same window? Like child tabs as well as label tabs, that are links to other windows.
Another cool use of vertical tabs is for the tabs on the left to select between windows, and the tabs on the right select between children of the current window (not sub-windows, but related windows or sub-directories). And you can use the tabs along the top as breadcrumbs to navigate back up the tree.
Some IDEs kind of do that with a directory browser on the left and a function browser on the right, but with outlines and scrolling lists instead of actual tabs.
You could navigate the tab tree by clicking or gesturing left or right with a pie menu on a tab, sliding the right column of tabs over to the left to descend into the tree.
Like a Finder window that shows directories as tabs on the right instead of icons inside.
You could also have top and bottom edge tabs for different kinds of children (i.e. xml attributes vs elements, object methods vs properties, different views or editors, etc).
The original NeXT file browser had breadcrumbs along the top (but not tabs):
31 comments
[ 3.9 ms ] story [ 202 ms ] threadHow do you control all of that? That's where the pie menus on the tabs come in, of course. Thanks to the tabs, you can even pop up pie menus on windows that are completely covered up, and perform commands on them even though they're not visible, like bringing them to the top (stroke up) or down (stroke down), or closing them (diagonal stroke for confirmation submenu, then stroke up to confirm), or whatever (paste into terminal emulator, evaluate code in editor, etc).
I never knew you could drag the open editors list off to its own thing though.
TIL.
https://en.wikipedia.org/wiki/Tab_(interface)#/media/File:Hy...
Vertically tabbed windows combine synergistically well with pie menus, and are great for window management, especially when you have many windows.
They are purposefully NOT patented, since the idea is so fucking obvious, but it's disappointing they took so many decades to catch on finally. Still there aren't any decent desktop window managers I know of that implement tabs the right way. (tvtwm is not the right way!)
The later NeWS Toolkit versions from the early 1990's let you drag the tabs around to any side of the window you like: left, right, top or bottom, to any position along any edge. The user should be able to decide which edge and where the tabs are attached to for each window, it should not be hard wired like the tabs in VSCode and web browsers typically are. Being able to choose which edge the tab is on and where the tab is gives users better more flexible ways to organize and manipulate their windows.
https://en.wikipedia.org/wiki/Tab_(interface)
HCIL Demo - HyperTIES Authoring with UniPress Emacs on NeWS, tabbed windows, pie menus:
https://www.youtube.com/watch?v=hhmU2B79EDU
I had a video of the NeWS tabbed windows, demonstrating dragging the tabs to different window edges, but youtube took it down because it contained copyrighted music (Herbie Hancock's Rockit).
Oh, here's the original video you can download from my server:
https://donhopkins.com/home/movies/TabWindowDemo.mov
Here are some different version from 1988-1991 for different versions of NeWS:
https://donhopkins.com/home/archive/NeWS/tabwin.ps
https://donhopkins.com/home/archive/NeWS/tab-1.ps
https://donhopkins.com/home/archive/NeWS/tabframe-1.ps
https://donhopkins.com/home/archive/NeWS/tab-3.0.2.ps
Here's another NeWS program that uses vertical (by default, but any edge if you want) tabs on windows around PostScript objects that you can push and pop on the stack with "direct stack manipulation":
The Shape of PSIBER Space: PostScript Interactive Bug Eradication Routines — October 1989
https://donhopkins.medium.com/the-shape-of-psiber-space-octo...
PSIBER Space Deck Demo:
https://www.youtube.com/watch?v=iuC_DDgQmsM
That's also why I'm thankful when people don't assume 16:9 screen estate and configure their max line length to huge amounts like 120 or more! 80, 100 max, is still today the sweet spot. But I digress.
For an IDE I wouldn't use vertical tabs on a side. But for web browsing they've become second nature to me, and Tree Style Tab for Firefox [1] changed the way I use the browser!
[1]: https://addons.mozilla.org/en-US/firefox/addon/tree-style-ta...
Then you can assign meanings to each side, depending on your workflow, for example (this should be under user control, not set in stone, of course):
Tabs on the top for important stuff.
Tabs on the bottom for administrative stuff.
Tabs on left for things you haven't read yet.
Tabs on right for things you've already read.
Then drag the tab from the left to the right after you read something (like moving it from your "in box" to your "out box"), or pin its tab on the top or bottom of it's important and you want to keep it around and easy to find.
And if you really want, you should be able to hide the tab to save space.
And not only tabs for apps like browser and IDEs, but also the desktop window manager should support tabs on top level windows in a consistent manner, so you can drag tabbed windows in and out of other window frames, as well as arranging them in hierarchical outlines along the edges.
All this is super obvious, and saves a lot of time and effort, so it bewilders me why tabs like I described and implemented in the 1980's aren't universally supported on all desktops and applications by now.
It's not because they're patented. Adobe tried, and sued Macromedia over it, but that patent (illegitimate in my view, since it ignored the prior art, and was extremely obvious and not patentable) has long since expired.
https://www.metafilter.com/2805/Adobe-sues-Macromedia-over-i...
Maybe both these are cases of good ideas that were there at the right time and place, but lost steam because of patents, and then later the timing was just too late already.
In the case of games, loading screens are nowhere as lengthy as they were when the mini game idea would have been useful. Similarly, the all-tabs paradigm would nowadays be way out of scope for commercial desktop environment makers, who are deeply immersed in a crusade to make simpler and mobile-compatible UIs for their systems, and have been so, slowly but surely, for at least the last decade.
EDIT: albeit if the idea had been around since the 80's, then my reasoning doesn't hold water! 90's was the age of multi-document UIs on Windows, and I'd argue that was the best time the idea had to get some implementations, but I guess it didn't get too much popularity back then either, or maybe Microsoft evaluated and didn't bet on it.
https://en.wikipedia.org/wiki/Tab_(interface)#/media/File:Hy...
https://www.youtube.com/watch?v=hhmU2B79EDU
Not sure why though, is there something with the way it’s phrased that makes us think of the tab character? It’s not particularly ambiguous and I’m very aware that vertical tabs (not the character) exist so I have no idea why I first thought of the obscure vertical tab character
For me, a reason might be that I am not a native English speaker.
The "tab" meaning of the character, key, and typewriter mechanism is quite similar in German as in English ("[der] Tabulator" as the encompassing term, and specifically "[das] Tabulatorzeichen" (the character), "[die] Tabulatortaste" (the key), and "[der] Tabulatormechanismus" (the mechanism on a typewriter)).
On the other hand, the term for the GUI elements (derived from the office stationery) is quite different in German: "[der] Registerreiter" (for the GUI element that you click on to switch between tabs) and "[die] Registerkarte" (the content of a tab (tab page)).
While I know all the listed meanings of the English word "tab", the meaning of the first concept is the much more "natural" one for me.
It’s funny how the brain works sometimes.
big fan of the Arc browser UX so I am hopeful this is better as well.
What makes user interface designers so arrogant and sure of themselves and lazy that they think one particular side is the only side, and the best for everyone, no matter what your screen size, resolution, aspect ratio, layout, number of tabs, icon or label size, workflow, direction of text flow, handedness, visual acuity, physical dexterity, task, and preference?
And then when you inevitably run out of space for tabs along the one edge, instead of simply allowing you to put more tabs along the other edges, you either add more horizontal rows along the top, so you get this abomination [1], or you have tiny little hard to use scrolling arrows at each edge so you can't see all the tabs at once, so you get that abomination [2]:
Is it ever okay to have multiple rows of tabs?
[1] https://ux.stackexchange.com/questions/15558/is-it-ever-okay...
Awesome Scrolling For Wide Tab-Interface Applications - ScrollTabs:
[2] https://www.jqueryscript.net/layout/Awesome-Scrolling-For-Wi...
It's like only putting only one arrow key on the keyboard.
But these days on my Dell 32" coding on the far left isn't that great, you actually have to turn your head.
I now split off a little left handed tab which I use to edit headers in code, for example includes, constants, enums, structs, variables and so on. Then just left of my natural forward eye position I have another tab for the rest of the screen and the code.
Another cool use of vertical tabs is for the tabs on the left to select between windows, and the tabs on the right select between children of the current window (not sub-windows, but related windows or sub-directories). And you can use the tabs along the top as breadcrumbs to navigate back up the tree.
Some IDEs kind of do that with a directory browser on the left and a function browser on the right, but with outlines and scrolling lists instead of actual tabs.
You could navigate the tab tree by clicking or gesturing left or right with a pie menu on a tab, sliding the right column of tabs over to the left to descend into the tree.
Like a Finder window that shows directories as tabs on the right instead of icons inside.
You could also have top and bottom edge tabs for different kinds of children (i.e. xml attributes vs elements, object methods vs properties, different views or editors, etc).
The original NeXT file browser had breadcrumbs along the top (but not tabs):
https://www.youtube.com/watch?v=rrTag7nSHlw&t=701s