Provide ui.linear_progress and ui.circular_progress elements

As written in https://github.com/zauberzeug/nicegui/pull/101#issuecomment-1268344725 we would like to see the Quasar progress types as NiceGUI elements. This should be straight forward as @hroemer showed in pull request #101.

@hroemer do you have a rough time estimate for this? We would love to see this feature in the next release. I personally needed it already twice 😄

@rodja sorry for the delay, I am quite busy at the moment. I think I should be able address this issue by the end of the next weekend.

@rodja I added components ui.circular_progress and ui.linear_progress in PR #144. I am not happy with the implementation, though.

• styling is inconsistent, as attribute size is not equally available in both upstream base components.
• the value range of QLinearProgress is 0.0 - 1.0, while QCircularProgress is 0 - 100!?

I got rid of the first issue by extending upstream components adding properties size and instant-feedback accordingly, although styling results feel a bit weird still.

The second concern regarding value ranges should be left as is, at least in the quasar component layer.

the value range of QLinearProgress is 0.0 - 1.0, while QCircularProgress is 0 - 100!?

I would like to have consistent value ranges in NiceGUI. If Quasar does it differently, we should do internal conversion. We prefer 0.0 - 1.0 ranges for percentage values.

Please try to avoid using the term "percentage" when describing the range 0.0 - 1.0. A term like "fraction" (or possibly "ratio", or "proportion") would be better. Reserve the term "percentage" for values in the range 0.0 - 100.0.

This seems pedantic, but I'm merely trying to avoid the confusion that I've seen so often in the past with this subject.

I would leave the keyword argument name value, though. Otherwise functions like bind_value_*** would not be obvious anymore.

Please try to avoid using the term "percentage" when describing the range 0.0 - 1.0. A term like "fraction" (or possibly "ratio", or "proportion") would be better. Reserve the term "percentage" for values in the range 0.0 - 100.0.

This seems pedantic, but I'm merely trying to avoid the confusion that I've seen so often in the past with this subject.

@bapowell Thanks for the clarification. I'm a bit sloppy with the terms but want to get better. Call me out anytime!

@hroemer I've taken the liberty to do some review, refactoring and API improvements directly within your code. Let me explain my changes:

• I removed the components QCircularProgressExtended and QLinearProgressExtended. We can simply extend the prop_list on the view itself. (Amazing that you spotted the missing props!)

• I removed the new progress elements from the binding example. Although it is a good intention to show the binding capabilities, it blows up this example a bit. I'd rather keep them short and concise.

• Instead I extended the progress examples a bit to demonstrate interactive manipulation with a slider involving value binding.

• I like the idea of implementing a value label for linear progress, even though Quasar only supports it for circular progress. To avoid the need for re-implementing what you did, I moved it into the LinearProgress class. I could simplify it a bit, so it's only a jp.Div with the right classes and binding. The bar size is adjusted depending on whether there is a label or not.

• I removed the Container class and the ContextMixin, because it is not needed anymore and we already have a general-purpose container element Group.

• I derived the progress elements from Element rather than ValueElement. The latter was intended as input element, which the progress elements are not. This simplifies things a bit.

• Instead of trying to convert values for circular progress, I made min and max available with the defaults being equal to linear progress' limits (i.e. from 0 to 1). So we have consistency and full control for the user without implicit conversions.

• In the flavor of already existing elements I reduced the argument lists a bit. But this is definitely a matter of taste and ongoing discussions.

I'm still a bit undecided if the labels should be visible by default or not. It is probably very valuable, but the plain value 0..1 is a bit strange. Percentages would be nicer, but more difficult to achive. And because one might want to show different units, we would need some more attributes for customization, e.g. label_format or label_suffix, which complicates the API again.

But maybe we close this issue for now and postpone improvements for later.

@falkoschindler thanks a lot for the comprehensive review and refactorings. I learned a lot about cleaning up the API / implementation.

Instead of trying to convert values for circular progress, I made min and max available with the defaults being equal to linear progress' limits (i.e. from 0 to 1). So we have consistency and full control for the user without implicit conversions.

Great solution! I can't believe I couldn't see the wood for the trees by just using min/max 🤦.

I'm still a bit undecided if the labels should be visible by default or not. It is probably very valuable, but the plain value 0..1 is a bit strange. Percentages would be nicer, but more difficult to achive. And because one might want to show different units, we would need some more attributes for customization, e.g. label_format or label_suffix, which complicates the API again.

But maybe we close this issue for now and postpone improvements for later.

:+1: