Add configurable workspace tab overflow

[mdcnick]

Summary

• keep the first five workspace panel tabs visible and move additional panels into a More dropdown
• promote a selected overflow panel into the visible tab set so users can customize which tabs stay pinned
• persist the pinned tab choices in localStorage and avoid duplicate “More” labels

Verification

• npm run verify

[jmfederico]

Thanks for this.

Before we go further, I'd like to understand one thing: what made you want to move away from the horizontal scrolling we have today? Scrolling keeps every tab visible and in place, so I'd like to know what wasn't working about it before we swap it out.

A few things I hit while testing:

1. I can't choose which tabs stay visible. The set just happens on its own, with no way to pin or unpin.
2. The tabs jump around. Picking one from "More" pushes it into the bar and bumps another out, so the layout keeps reshuffling.
3. The 5-tab limit feels arbitrary. It's not based on available space or adjustable, so it hides tabs that would easily fit on a wide screen.

I also hit a bug that left me stuck:

1. Fresh load: "Info" is the open tab, "Updates" is tucked away in the "More" dropdown.
2. I pick "Updates" from the dropdown. It opens, and jumps up into the tab bar. "Info" gets bumped down into "More".
3. I click "Terminal".
4. Now "More" still shows "Updates" as if it's selected, but I can't get back to "Info". Choosing it from the dropdown does nothing, so I'm stuck.

So once a tab has been promoted out of the dropdown, the dropdown can get into a state where I can't navigate back to the other hidden tabs.

I would like to have a clearer idea of the motivation so we can land on a solution that fits a problem we both understand

[mdcnick]

The reason I wanted to move away from relying only on horizontal scrolling is that it becomes unreliable once there are a lot of tabs. Sometimes the scroll accordance disappears or is easy to miss, and users can lose track of where certain tabs are. My thought was to make the important tabs more stable and easier to access instead of having everything depend on scrolling left and right.

That said, I agree the current behavior is not quite right yet.

What I actually want is probably closer to:

Let users choose which tabs stay visible / pinned.
Keep the visible tabs stable instead of automatically reshuffling them.
Put overflow tabs into “More” based on available space, not a hard 5-tab limit.
Allow users to swap tabs in and out intentionally.
Make sure selecting a hidden tab from “More” never traps or hides another tab in a broken state.
So I don’t think the goal is simply “replace scrolling with More.” The goal is to make grouped tabs easier to manage when there are many tabs, especially by letting users control which tabs stay up top.

The bug you found sounds valid too: selecting a tab from “More” should not leave the drop-down showing the wrong selected tab or prevent navigating back to another hidden tab. That should be fixed regardless of the final UX direction.

Maybe the next iteration should focus on making tab grouping/pinning more intentional rather than automatically promoting and bumping tabs around.

[jmfederico]

I understand, I think it makes sense.
I would like to keep both options though. I for one enjoy the horizontal scroll pattern and do not want to loose it, but I understand this does not fit everyone.

I would be more than happy to merge a solution that would allow users to decide which tabs they want to hide, maybe that could be done by some ordering mechanism that could even be used in horizontal scroll mode as well, and that keeps a stable interface (elements should not swap positions constantly)