Add an "indeterminate" mode to the ProgressBar control

[ckaiser]

Describe the project you are working on

A game with networking or anything that has the user waiting for something with an unknown progress.

Describe the problem or limitation you are having in your project

Some actions with unknown progress should have a visible indication that something is happening, in my case this is establishing a network connection and initial sync and then loading from a resource, the second part can be easily shown using a ProgressBar, but not the first, considering it's all part of the same "progress" of loading into a game map, it'd be nice if it could be solved with just one control.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

It's easy enough to indicate progress through other means but it'd be good for ProgressBar to provide a simple checkbox toggle for "indeterminate" mode that could be switched on an off when the exact progress of the task is unknown but you still want to make clear to the user that something is happening.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

We can add a boolean "indeterminate" property to ProgressBar, when checked this would supersede the current rendering (no percentage shown and no current value shown in the bar since these wouldn't make sense) and we'd get something like this:

poc_loop.mp4

This is a POC I already have implemented, should be easy to polish it up for a PR.

If this enhancement will not be used often, can it be worked around with a few lines of script?

You can't really achieve the same look just scripting the ProgressBar since it always starts from either the left or the right, you can always make a custom control but if you want it to follow the application theme it's a bit bit more complex.

Is there a reason why this should be core and not an add-on in the asset library?

This would make the ProgressBar node more useful in a broader set of scenarios.

[Calinou]

Sounds good to me. This makes sense to implement as ProgressBar is often used in non-game applications. TextureProgress is less likely to benefit from this as it's primarily used for game UI where indeterminate progress is uncommon (and tends to favor bespoke animations).