feat(tab-progress-bars): add tab and single-tab progress bars

[claaslange]

PoC for feature request https://gitlab.com/gnachman/iterm2/-/work_items/12808

The version in here respects the session settings for progress bars (hide/show and color scheme). If only a single tab is opened the progress bar is shown at the top of the session view, as soon as multiple tabs are opened the progress bar moves to the tab itself.

[claaslange]

On second look through the code I realized that the spinner already handles basically everything. The only thing that confused me so far is the spinner disappearing when the tab is selected. If the spinner would always be visible while work is ongoing, it would solve my request already.

[kud]

Would be nice!

[gnachman]

Thanks for the PR! This is a nice proof of concept. A few things to address:

Tahoe tab style: The progress bar needs to be enclosed within the pill-shaped tab when drawn in the active tab. Right now it's positioned at the bottom of the cell frame, which will extend outside the pill shape.

Inline progress bar visibility: When there are split panes, inline progress bars should still be shown. Likewise, when the tab bar is not visible (e.g., in fullscreen, tabs are sometimes hidden), inline progress bars should remain visible since there's no tab to show progress on.

showInlineProgressBar ownership: PTYSession should not be reasoning about showInlineProgressBar — that logic should be delegated to the window controller (WindowControllerInterface). Currently both PTYSession (in reallySetPreferencesFromAddressBookEntry:) and PseudoTerminal (in updateSessionProgressBarVisibility) have logic to calculate and set the value of SessionView.showInlineProgressBar, and they compute different things. This should live only in PseudoTerminal.

Progress bar ownership: It's questionable to have iTermTabBarControlView hold the _tabProgressBars dictionary. It would make more sense for PSMTabBarControl to own them, similar to how it owns PSMProgressIndicator. That way, when tabs move from one window to another, the progress bar naturally follows without having to manage that in a second place.

[claaslange]

Thanks for the detailed feedback. I tried to incorporate it. Disclaimer: The heavy lifting was done with the help of GPT-5.4 as my last excursion into Objective-C dates 10 years back.

I also have no access to a Mac running Tahoe, so I'm flying blind there.

[kud]

Out of curiosity, how do we trigger those loaders from zsh or Node? I find them really cool and wonder how to trigger them. cc @gnachman

[claaslange]

It's described in the progress bar section at https://iterm2.com/documentation-escape-codes.html

[kud]

@claaslange Thank you!

[claaslange]

I've also experimented with displaying the progress bar in vertical orientation, if the tab bars are in vertical orientation. This makes it a bit easier to see which tab is in which state. For horizontal tabs it can stay at the top.

The tabs show all examples from the documentation.

[claaslange]

I've added a setting to the Advanced -> Tab section to switch between horizontal and vertical progress bars on horizontal tab bar. When using it daily the vertical bars are a lot less confusing.

[kud]

@claaslange We might have an issue with that as I also use the top border for the tab groups. I'm happy to find another way but I think it would be beneficial to discuss about the UI direction we want.

[claaslange]

@kud this relates to #594, correct? So far it only contains one screenshot, so I can't really tell how prevalent the group borders are but both definitely compete for the same area in the ui. For me this mostly boils down to the direction that @gnachman wants to take his project. I simply decided to re-use the existing progress bar and placed them at the top of bars to replicate what is happening in the session view. The one thing I already learned however is that this feature makes a big difference as soon you work with more than one coding agent in parallel 😅

As I wrote earlier we could change the approach of this PR to take over the existing progress indicator (spinner/blue circle) that appears at the right hand side of the tab:

In that case the approach would change a little bit:

• Session uses OSC 9;4 sequences -> progress indicator should only follow those
• Session does not use OSC 9;4 sequnces -> progress indicator behaves like it does today

We might replace the spinner with a green circle that's animated similarly to the progress bar. Combined with tab groups it might still feel a bit like "disco" though.

[gnachman]

Merged with changes as commit 6908b3d. Thanks!

[claaslange]

@gnachman Did you decide to leave out the option for vertical progress bars on purpose? I find them a lot clearer (albeit unusual for sure) for tabs on the left. If you'd still consider it, I'm happy to provide a separate PR for it.

[kud]

@claaslange @gnachman It's quite intense. Is there a way I can disable the progess bar on the pane while I keep it on the tab, by any chance? The double progress bar is too much for me.

[gnachman]

@gnachman Did you decide to leave out the option for vertical progress bars on purpose? I find them a lot clearer (albeit unusual for sure) for tabs on the left. If you'd still consider it, I'm happy to provide a separate PR for it.

It didn't look right to my eye. I agree that it was clearer, but I think the look was so odd that it outweighted the benefit of clarity—and I also think the clarity benefit would be short-lived as you'll get used to knowing how they relate to the tab.