Allow the user to &#34;Pin&#34; tabs #8227

@DHowett commented on GitHub (May 18, 2020):

Triaged tentatively 2.0

@DHowett commented on GitHub (May 18, 2020): Triaged tentatively 2.0

claunia commented

@electronic-dk commented on GitHub (May 19, 2020):

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?

@electronic-dk commented on GitHub (May 19, 2020): 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?

claunia commented

@zadjii-msft commented on GitHub (May 19, 2020):

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.

@zadjii-msft commented on GitHub (May 19, 2020): 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.

claunia commented

@catthehacker commented on GitHub (Jun 30, 2020):

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

Default Firefox

@catthehacker commented on GitHub (Jun 30, 2020): 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](https://user-images.githubusercontent.com/31106839/86169834-c4dae100-bb09-11ea-9051-a8fdd3a84f0c.png) Default Firefox ![image](https://user-images.githubusercontent.com/31106839/86170383-93164a00-bb0a-11ea-9b47-fb9c91e19eae.png)

claunia commented

@stmoy commented on GitHub (Jul 1, 2020):

@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?

@stmoy commented on GitHub (Jul 1, 2020): @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?

claunia commented

@marcelwgn commented on GitHub (Jul 1, 2020):

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

@marcelwgn commented on GitHub (Jul 1, 2020): 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

claunia commented

@teaP commented on GitHub (Jul 1, 2020):

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.

@teaP commented on GitHub (Jul 1, 2020): 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.

claunia commented

@ADTC commented on GitHub (Jul 23, 2021):

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.

@ADTC commented on GitHub (Jul 23, 2021): 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.

claunia commented

@zadjii-msft commented on GitHub (Jul 26, 2021):

@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.

@zadjii-msft commented on GitHub (Jul 26, 2021): @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](https://github.com/microsoft/terminal/issues/5969#issuecomment-652550757) 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.

claunia commented

@Exerosis commented on GitHub (Jan 10, 2024):

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.

@Exerosis commented on GitHub (Jan 10, 2024): 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.

claunia commented

@pfeileon commented on GitHub (Feb 29, 2024):

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.

@pfeileon commented on GitHub (Feb 29, 2024): > 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.

claunia commented

@Exerosis commented on GitHub (Feb 29, 2024):

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)

@Exerosis commented on GitHub (Feb 29, 2024): > > 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)

claunia commented

@felipecrs commented on GitHub (Aug 7, 2024):

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

@felipecrs commented on GitHub (Aug 7, 2024): Is there any update since the last one? This feature would be very nice.

claunia commented