Proposal: ProgressRing in TabViewItem

[Leisvan]

Proposal: ProgressRing in TabViewItem

In TabViewItem, it'd be useful if you add a progress ring in the same place the glyph is.

Summary

Commonly, a TabViewItem holds some content, which may take time to load. That's why a progress ring instead of a glyph may be a good idea, a property like IsLoading could be set on or off to switch from the glyph to the progress ring. Something like Edge Tabs.

[mrlacey]

As a more general solution, it would be good to see the ability to use an animated Gif for the TabViewItem image then this could be a loading animation or something else.

Only adding support for a progress ring seems too limiting and potentially paves the way for future requests to embed other primitives in the TabViewItem header too.

A version of ImageSource that supports animated gifs could be useful in other places too.

[mdtauk]

Once the ProgressRing control is updated in it's design, and to add a Determinate mode - there could be fuller support with TabLoading events, which would display only the Progress Ring or Progress Bar value, or indeterminate animation, and then load in the Tab Title, and Tab Icon.

[jevansaks]

@stmoy Seems like a nice QoL improvement to add an "IsLoading" property to TabViewItem?

[stmoy]

Interesting idea! I added it to the list of things to consider in TabView vNext (#1332).

In the spirit of separation of concerns, I don't know if adding "IsLoading" to TabViewItem is the way to go specifically because it's generally not the TabViewItem that is loading -- it is the content inside. Instead, we could consider something like TabViewItem.ShowLoadingIndicator or something to represent the UI piece.

@mrlacey and @mdtauk bring up a good points that we probably would want to support general solutions in addition to just a regular ol' progress ring. I'd imagine we'd also want to support GIFs, determinant progress rings, or potentially even progress bars.

Exploring a bit further: what if we did want to support determinant progress ring? Does that mean that we'd also have TabViewItem.LoadingProgressValue and related properties/events? I suspect this would cause an explosion of APIs on TabViewItem.

In the short-term, this should be achievable just using the TabViewItem's Header property. Not optimal, but possible.

[Leisvan]

Thanks for considering my proposal. Using the TabViewItem's Header to display the ring gave decent results but I though maybe native support for this situation could be something to suggest.

[mdtauk]

If it is a common enough scenario, that would warrant a default way of doing it being added, perhaps gated behind a behaviour. So unless say TabItemsCanLoad is true, the progress control would not be added to the Visual Tree.

[robloo]

Why don't developers just put a StackPanel in the TabViewItem Header with a ProgressRing and TextBlock?

Alternatively, why not just have an additional content control to place an item next to the tab view item header? Then developers could add FontIcons, ProgressRings, Images or whatever they want.

XAML is so powerful because it's really quite generic. Adding little things like this to the control itself seems like a bad path to go down long term. Styles/templates should be as simple as possible and developers can override them when they need to.

[mdtauk]

The idea about building it into the control, rather than having Dev's do it themselves, would be:

• a consistent look and behaviour from app to app;
• events in the control for Tab loading and loaded which could be useful for extending;
• styles that can be overridden would be available;
• the loading state could be templatable;

[zadjii-msft]

To throw 2¢ in from the Terminal team:

This is definitely a feature I'd look for as well. One thing we want to support in the future is the ConEmu "progress" VT sequences, which can be used for setting the "taskbar progress status" for the terminal. Since we could have multiple tabs, each with their own progress status, I'd love if there was a way to display this status within each tab as well, not just in the taskbar :)

See also https://github.com/microsoft/terminal/issues/3004

[mdtauk]

To throw 2¢ in from the Terminal team:

This is definitely a feature I'd look for as well. One thing we want to support in the future is the ConEmu "progress" VT sequences, which can be used for setting the "taskbar progress status" for the terminal. Since we could have multiple tabs, each with their own progress status, I'd love if there was a way to display this status within each tab as well, not just in the taskbar :)

See also microsoft/terminal#3004

When/If the status bar gets added to Terminal, this would also be a good place to display a progress element.

[zadjii-msft]

@mdtauk that's certainly an idea, but I definitely don't want to preclude the Terminal from being able to display the progress in tabs themselves. One could imagine a user whose running a build in one tab, and is doing some other work in another tab while that build is running. Displaying the progress right in the tab itself would allow the user to visually check on the status of the build without necessarily switching the active tab.

[mdtauk]

@mdtauk that's certainly an idea, but I definitely don't want to preclude the Terminal from being able to display the progress in tabs themselves. One could imagine a user whose running a build in one tab, and is doing some other work in another tab while that build is running. Displaying the progress right in the tab itself would allow the user to visually check on the status of the build without necessarily switching the active tab.

Sure, I mean one implementation of progress, can power both controls.

That would mean as well as the loading of a Tab powering the Progress Ring, there would need to be control events/methods to control the Progress Ring when it is visible. And it will need a progress value to be passed, as well as an indeterminate implementation.