search

microsoft / terminal

The new Windows Terminal and the original Windows console host, all in the same place!
MIT License
94.89k stars 8.22k forks source link

Allow the user to "Pin" tabs #5969

Open zadjii-msft opened 4 years ago

zadjii-msft commented 4 years ago

With #5787 merging soon, we'll be able to have compact tabs, the same size as "pinned" tabs in lots of browsers.

We should add a context menu option to let users pin tabs as well. When tabs are pinned, they'd move to the start of the list of tabs, to the left of the test of the tabs. We'd probably need to have different lists for pinned vs normal tabs.

Trickily, pinned tabs could only be reordered within the range of the pinned tabs - so it can't be [pinned, pinned, normal, pinned, normal] tab. That might be tricky to pull off.

A follow-up could be linked to #961 where the pinned tabs are re-started, but not the unpinned ones. I think this is kinda similar to how browsers handle pinned tabs. We'd need to reconcile this with #756 - If the user has tabs pinned, then do those re-open, and the startup configuration the user specifies? We'd want to have a comprehensive story before we start on either story.

DHowett commented 4 years ago

Triaged tentatively 2.0

electronic-dk commented 4 years ago

I have small question: is this going to be implemented in Terminal or is it expected to update to a future tab control version which supports this functionality in scope of this ticket?

zadjii-msft commented 4 years ago

In my opinion, it certainly makes sense to just have it implemented in the TabView itself, but we'd have to work with @stmoy and @teap on that to see if this would make the cut for inclusion in a future MUX release.

catthehacker commented 4 years ago

If Terminal is going the "browser design" route, it would be nice to make it a bit more customizable (Firefox is nice example here) where we could move some things around, e.g.: add spacer, move menu from one side to the other image Default Firefox image

stmoy commented 4 years ago

@zadjii-msft - I agree that TabView should enable this scenario, though I don't think it'd have the "pin tab" behavior built-in. For example, I wouldn't expect TabView to save the pinned tabs if the app closes and opens again - it'd be the responsibility of the app to maintain that state.

@chingucoding introduced compact sized tabs in 2.4, but they affect the entire TabView. IIRC the width setting is not settable on the individual tab items, so that'd probably be the feature that TabView would need to expose. Since the compact sizing template is included with the TabView now, I wonder if it'd be possible to hack together a proof of concept for tab pinning; @chingucoding @teaP - thoughts?

marcelwgn commented 4 years ago

While the TabView maintains the "compact/non compact" setting, every TabViewItem is aware whether it is in Compact mode or not (which is also why #6670 was needed). That said, this knowledge of compact/not compact is only available internally and not a public API. Having specific items have different sizing behavior as others would make layouting quite difficult.

Regarding a proof of concept for tab pinning would be the question whether it can be done inside the WinUI repo where we have access to internal APIs or whether it should be in the terminal code base. The latter case will probably get a bit difficult as you would need to try to revert any sizing behavior the TabView and its items are trying to keep up. But theoretically, mocking pinned tabs could work with a bit of VisualStateManager fiddling.

PS: Thanks for the ping @stmoy

teaP commented 4 years ago

If we did pinned tabs, they would have to be in their own list; it wouldn't just be an ordering thing. My guess is that Terminal could get pretty close by simply having two TabViews next to each other (minus, probably, some layout issues). It also wouldn't be too hard to put together a proof of concept where TabView handles it internally.

ADTC commented 3 years ago

What is the timeline for this, please? It would solve another issue for me.

I have tabs that are permanently running processes (in foreground so I can see the logs, restart as needed, etc.). Right now, if I accidentally hit the X button, the tab kills the process immediately without any warning (see #5301). With a pinned tab, I wouldn't have the chance to accidentally close it anymore, since the tab would only have the width of the icon and not have the close button anymore.

Also, it would free up space on the tab bar for non-pinned tabs that I temporarily open for issuing ad-hoc commands. Right now, the tabs running foreground processes take up so much space without pinning, that the additional tabs just get crushed up on the tab bar.

zadjii-msft commented 3 years ago

@ADTC There's no timeline for this currently - it's simply on the "backlog". We'd absolutely accept an external contribution for this feature, but we're likely not getting to this on this side of 2022.

I think this comment has a great idea of how to start the work on this. The trick is that we currently do a lot of work on tabs by their index in the list - if there were two separate lists of tabs, then that math would get more confusing.

Exerosis commented 8 months ago

I propose that an initial version of pinning be released but keep the indexing the same. For example you might have 3 pinned tabs followed by an unpinned tab and then another pinned tab. I'm not sure about most people's use cases; for me, it's about not accidentally closing important terminals, not really about organizing tabs.

pfeileon commented 6 months ago

I propose that an initial version of pinning be released but keep the indexing the same. For example you might have 3 pinned tabs followed by an unpinned tab and then another pinned tab. I'm not sure about most people's use cases; for me, it's about not accidentally closing important terminals, not really about organizing tabs.

I wouldn't call that pinning but locking. Imho that's a different feature.

Exerosis commented 6 months ago

I propose that an initial version of pinning be released but keep the indexing the same. For example you might have 3 pinned tabs followed by an unpinned tab and then another pinned tab. I'm not sure about most people's use cases; for me, it's about not accidentally closing important terminals, not really about organizing tabs.

I wouldn't call that pinning but locking. Imho that's a different feature.

Perhaps, but if pinning is difficult to implement and locking is not then it might be a good first step that satisfies at least some people. (if all I could do was lock tabs on edge/chrome I would still be happy with the feature)

felipecrs commented 1 month ago

Is there any update since the last one? This feature would be very nice.