Changes to Orion's Sidebar / Vertical tabs handling

ForumNinja404

Correct me if I’m wrong, your proposal is that rather than groups be in a dropdown, they are shown directly in the tree?

my proposal is that tabs are shown in the “windows” sidebar, not that windows are shown in the tabs sidebar. Small but important distinction.

However, The distinction of temporary tabs seems unnecessary and very misleading.

Perhaps my wording was off, I didn’t mean to suggest any such “temporary tab” concept. I’m just suggesting that how orion handles temporary tab groups should be similar to how arc handles temporary tabs.

The sidebar should not have a section for unnamed groups, it should all be a unified tree.

I argue this is even more misleading.

Since this is the ”windows” sidebar, its not shown by default in a new unnamed window. What the user sees will be no different from what they would see right now. The separation is there because when the window containing the tab group is closed, that tab group is closed too. This is unlike regular saved groups, that retain. They have different behaviours and putting them together in that way seems nonsensical.

How does one zoom in / out of the directory tree? Zooming in defeats the purpose of showing all the groups at once.

The purpose of tab groups here is to have different things that you don’t need to see all the time. It helps not to hink of the regular tab tree as a "zoomed in" version of the tab groups tree, but that the tab groups tree is a "zoomed out" version of the regular tab tree. Within a tab group (the regular tab tree), you see what you would normally see right now in Orion. "zooming out" (probably by clicking the window switcher) just shows you your other tab groups, that you may not need all the time.

For example, I usually use tree tabs in a way similar to what I'm proposing, within a single window. I collapse + suspend them whenever I don't need them, and do the opposite whenever they are needed. This is so that when they're not needed, I don't see them, but I can easily (within one click) see what tabs there are and switch to them if needed. My proposal is just a more integrated version of that.

It’s also not viable with horizontal tabs. The current implementation (while less transparent) works for both tab views and is confined to a single button.
and
The new UX would allow users to switch between groups quickly and move tabs between them. With horizontal tabs, there’s not an easy way to make this work. Collapsible accordions are notoriously bad and dragging tabs between them would get difficult with a single tab strip.

Apple shows both, but Vlad mentioned in the discord that it is an inelegant solution. My idea for this is that the current tab group within the Tab Groups sidebar doesn't show its tabs, and they are instead shown in the horizontal tab mode.

Why not have the full tree always visible? When the user switches to a tab in another group, the other groups collapse and the current group is marked as active.

Because you might not want to see the other tabs within other tab views. The Tab Groups sidebar is not intended to be a full replacement for the vertical tabs sidebar.

How are multiple windows handled? While I’d generally agree that a group should only be open in one window at a time, but this makes the new tree less powerful.

I decided to only allow one open window for each group at a time because that is how Orion currently works. My proposal would not make orion's tab groups any weaker than they are now.

If a user is currently in group A, what happens if they click a tab in group B? Do they jump directly to that other open window? That seems like a bad user experience.

I'm thinking that this is similar to current in-place window switching when the target window is already open. Orion just switches to the already open window, and I think that this is the best user experience in this case. Other possible behaviours:

• The existing window closes, current window switches in-place
• The active tab groups in the windows swap
  But I think just switching to the open window is the most predictable.

Groups are folders that are not bound to a specific window, they simply provide structure.
Exactly, thats why I want to fix the terminology used.

The easiest way I can think of is to rename the “Windows Sidebar” to “Group Sidebar and show the full tree there.
Well yeah, thats kinda the proposal in a nutshell. The only additional thing is the separation of the temp and named tab groups.

Vlad
With regards to these ideas, my idea would work fine with the sidebar url bar, since its just an upwards extension of the vertical tabs concept. It is a revamp of the "Windows" sidebar and doesn't have a large impact on the regular Tabs sidebar.

As for joint sidebars, I don’t think that my idea would work very well with it. Since it could show EVERY SINGLE TAB that the user has (if all tab group disclosures are expanded), its going to be so vertically tall that adding other sidebars to the bottom would be such a hassle to use that it wouldn’t be worth using. The only way I see it working is if its implemented similar to VSCode (image below), where each section can be resized and each scrolls individually.

The important things that I think orion needs to solve before it can grow out of this issue are:

1. The terminology needs to change ("window" -> "tab group")
2. The "workspace" must be visualisable
3. It needs to be obvious what the state of tabs within non-active tab groups aer

The way this proposal solves point 2 is by animating the transition, so the workspace is just an extension of the tab groups. 3 is solved because tab groups behave similarly to the vertical tabs sidebar, so you can see that the tabs are/are not suspended, and you can take actions on them by right click suspend tree as you would a tab tree.