WIP: UI: Progress Indicator Variations #109882

Harley Acheson · 2023-07-09T21:53:47+02:00

Harley Acheson commented

2023-07-09 21:53:47 +02:00

Ring style of progress indicators. Exposes progress bar to the
python API and adds a "type" property to allow style variation.

The Extensions project might need a ring style of progress indicator. This WIP adds a "type" property for BAR and RING. For testing it adds one of each to the Console Editor header with:

layout.progress(factor = 0.5)
layout.progress(factor = 0.8, type = 'RING', text = "Updating")

Ring style of progress indicators. Exposes progress bar to the python API and adds a "type" property to allow style variation. --- The Extensions project might need a ring style of progress indicator. This WIP adds a "type" property for BAR and RING. For testing it adds one of each to the Console Editor header with: ``` layout.progress(factor = 0.5) layout.progress(factor = 0.8, type = 'RING', text = "Updating") ``` ![image](/attachments/66c1c4d1-f9da-42a3-ab6c-562596dc8017)

image.png

11 KiB

image.png

12 KiB

image.png

6.6 KiB

image.png

7.9 KiB

👍 8 ❤️ 8 🎉 1 🚀 5

Harley Acheson added 1 commit 2023-07-09 21:53:57 +02:00

4d521276ae WIP: UI: Progress Indicator Variations

Pie and ring styles of progress indicators. Exposes progress bar to the
python API and adds a "type" property to allow style variation.

Harley Acheson added this to the User Interface project 2023-07-09 21:55:14 +02:00

Harley Acheson added 1 commit 2023-07-10 03:02:47 +02:00

0d86a39d63 argument changes

Campbell Barton commented

2023-07-11 03:24:02 +02:00

Nice, some high level feedback.

This could be named progress_indicator since BAR is just a style.
It would be good to support text in BAR style, for RING/PIE styles, the text could simply be a label afterwards.

e.g. layout.progress_indicator(progress=0.5, style='BAR', text="Downloading...")

Or, an alternative could be to have a progress_bar(..) which takes a text argument and a progress_pie() function which doesn't, then leave it up to the caller if they want to add a label after the progress_pie().

It would also be good to support pulse=True for progress indicators which don't represent a beginning/end. This isn't needed for an initial version of this though.

Nice, some high level feedback. - This could be named `progress_indicator` since BAR is just a style. - It would be good to support text in BAR style, for RING/PIE styles, the text could simply be a label afterwards. e.g. `layout.progress_indicator(progress=0.5, style='BAR', text="Downloading...")` Or, an alternative could be to have a `progress_bar(..)` which takes a `text` argument and a `progress_pie()` function which doesn't, then leave it up to the caller if they want to add a label after the `progress_pie()`. ---- It would also be good to support `pulse=True` for progress indicators which don't represent a beginning/end. This isn't needed for an initial version of this though.

Harley Acheson added 1 commit 2023-07-11 20:06:17 +02:00

b6bb7ad262 Updated to incorporate changes suggested by review

Harley Acheson commented

2023-07-11 20:20:17 +02:00

@ideasman42 - This could be named progress_indicator

Done.

It would be good to support text in BAR style, for RING/PIE styles, the text could simply be a label afterwards.

This does so now, and I updated the capture in the first post. Seems to work well, but I am unclear about how to determine the width of the uiBut in uiItemProgressIndicator. Just picking arbitrary values is probably wrong.

It would also be good to support pulse=True for progress indicators which don't represent a beginning/end. This isn't needed for an initial version of this though.

My thoughts on this could be very wrong. But my idea is that we add new progress indicator types like UI_PROGRESS_INDETERMINATE_LINEAR, UI_PROGRESS_INDETERMINATE_SPINNER, etc. These increment their own progress value when drawing, then use a timer to trigger a refresh of their region? I have done something similar to get our text cursors to flash on and off and it seemed to work.

> @ideasman42 - This could be named `progress_indicator` Done. > It would be good to support text in BAR style, for RING/PIE styles, the text could simply be a label afterwards. This does so now, and I updated the capture in the first post. Seems to work well, but I am unclear about how to determine the width of the uiBut in uiItemProgressIndicator. Just picking arbitrary values is probably wrong. > It would also be good to support `pulse=True` for progress indicators which don't represent a beginning/end. This isn't needed for an initial version of this though. My thoughts on this _could be very wrong_. But my idea is that we add new progress indicator types like UI_PROGRESS_INDETERMINATE_LINEAR, UI_PROGRESS_INDETERMINATE_SPINNER, etc. These increment their own progress value when drawing, then use a timer to trigger a refresh of their region? I have done something similar to get our text cursors to flash on and off and it seemed to work.

Harley Acheson added 1 commit 2023-07-11 20:47:24 +02:00

7fccb366c6 Some cleanup, renaming, etc

Campbell Barton referenced this issue from a commit

2023-07-12 06:03:23 +02:00

UI: add progress indicator variations & RNA API

Campbell Barton commented

2023-07-12 06:03:39 +02:00

Committed c6adafd8ef with minor changes.

Committed c6adafd8ef325de6e925e30504882057d8455a8f with minor changes.

Campbell Barton closed this pull request

2023-07-12 06:03:40 +02:00

Dalai Felinto commented

2023-07-13 11:51:31 +02:00

A bit late to the party, but a few comments:

The progress bar type should only get a show_text option. Having the text match the value itself is error prone given that we would always want them to match.
I would either have ... always shown in the pie bar (as part of the internals), or discourage it completely.
Do we need ring AND pie progress indicators?

I also find the reasoning for the patch a bit weak: "The Extensions project might need ...". I would rather see changes in Blender for things we know already that are going to be used/useful. But I' m assuming this is part of the UI module long TODO list? I wonder if @pablovazquez was involved (or should've been involved in the review at least).

A bit late to the party, but a few comments: * The progress bar type should only get a `show_text` option. Having the text match the value itself is error prone given that we would always want them to match. * I would either have `...` always shown in the pie bar (as part of the internals), or discourage it completely. * Do we need ring AND pie progress indicators? I also find the reasoning for the patch a bit weak: "The Extensions project **might** need ...". I would rather see changes in Blender for things we know already that are going to be used/useful. But I' m assuming this is part of the UI module long TODO list? I wonder if @pablovazquez was involved (or should've been involved in the review at least).

Harley Acheson commented

2023-07-13 17:06:06 +02:00

@dfelinto - * The progress bar type should only get a show_text option. Having the text match the value itself is error prone given that we would always want them to match.

As mentioned in the first comment the text shown is optional. Our existing progress bar (before this PR) did not show the value as text, and we often display it too small for this to be possible. Having the text as an optional argument allows things like showing "Downloading..." as shown in the first comment. This behavior was requested by Campbell.

I would either have ... always shown in the pie bar (as part of the internals), or discourage it completely.

I am unclear what you are asking with this.

Do we need ring AND pie progress indicators?

It is a one-line addition to get both, as the difference between the two is in a single variable. Campbell asked for a "pie" style progress indicator, while I prefer a "ring" style so I gave him both. I anticipate other styles as well, including indeterminate versions like waiting "spinners" and pulse-style bars.

I also find the reasoning for the patch a bit weak: "The Extensions project might need ...". I would rather see changes in Blender for things we know already that are going to be used/useful.

I didn't concern myself much with the choice of the word "might" verses "will", "could", "should", or "shall" in the PR description.

But I' m assuming this is part of the UI module long TODO list?

This was something specifically requested by Campbell for the Extensions project. They are very likely to need it, but I am not requiring them to do so, so "might" was the most appropriate word.

> @dfelinto - * The progress bar type should only get a `show_text` option. Having the text match the value itself is error prone given that we would always want them to match. As mentioned in the first comment the text shown is optional. Our existing progress bar (before this PR) did not show the value as text, and we often display it too small for this to be possible. Having the text as an optional argument allows things like showing "Downloading..." as shown in the first comment. This behavior was requested by Campbell. > I would either have ... always shown in the pie bar (as part of the internals), or discourage it completely. I am unclear what you are asking with this. > Do we need ring AND pie progress indicators? It is a one-line addition to get both, as the difference between the two is in a single variable. Campbell asked for a "pie" style progress indicator, while I prefer a "ring" style so I gave him both. I anticipate other styles as well, including indeterminate versions like waiting "spinners" and pulse-style bars. > I also find the reasoning for the patch a bit weak: "The Extensions project **might** need ...". I would rather see changes in Blender for things we know already that are going to be used/useful. I didn't concern myself much with the choice of the word "might" verses "will", "could", "should", or "shall" in the PR description. > But I' m assuming this is part of the UI module long TODO list? This was something specifically requested by Campbell for the Extensions project. They are very likely to need it, but I am not requiring them to do so, so "might" was the most appropriate word.

Dalai Felinto commented

2023-07-13 17:24:13 +02:00

Hi Harley,

I would either have ... always shown in the pie bar (as part of the internals), or discourage it completely.
I am unclear what you are asking with this.

For consistency basically. If we decide that progress messages should have ... then we incorporate this in the API. I don't think this should be an option to person using it, but instead part of our core UI guidelines/design.

It is a one-line addition to get both (...).

I'm glad it wasn't a lot of work to do those variants. That said this is hardly a reason to justify more options on the Blender UI. We want the experience for everyone using Blender to be similar, and allowing add-ons (or even the core Blender) to deviate from that can affect this.

As a user if I see that something uses a full circle, something else uses a ring, I would like to understand what is the difference between them. If they have the same meaning/use then they should look/behave the same.

Hi Harley, >> I would either have ... always shown in the pie bar (as part of the internals), or discourage it completely. > I am unclear what you are asking with this. For consistency basically. If we decide that progress messages should have `...` then we incorporate this in the API. I don't think this should be an option to person using it, but instead part of our core UI guidelines/design. > It is a one-line addition to get both (...). I'm glad it wasn't a lot of work to do those variants. That said this is hardly a reason to justify more options on the Blender UI. We want the experience for everyone using Blender to be similar, and allowing add-ons (or even the core Blender) to deviate from that can affect this. As a user if I see that something uses a full circle, something else uses a ring, I would like to understand what is the difference between them. If they have the same meaning/use then they should look/behave the same.

Duarte Farrajota Ramos commented

2023-07-13 17:38:36 +02:00

First-time contributor

Personally I rather see a ring over the pie as well, but its up to personal preference.

As a user if I see that something uses a full circle, something else uses a ring, I would like to understand what is the difference between them. If they have the same meaning/use then they should look/behave the same.

I'd rather think of it as a global option set in preferences (say per theme for example) for the whole UI, rather than a decision someone would make on a per-use basis.

Personally I rather see a ring over the pie as well, but its up to personal preference. > As a user if I see that something uses a full circle, something else uses a ring, I would like to understand what is the difference between them. If they have the same meaning/use then they should look/behave the same. I'd rather think of it as a global option set in preferences (say per theme for example) for the whole UI, rather than a decision someone would make on a per-use basis.

Dalai Felinto commented

2023-07-13 17:45:06 +02:00

I'd rather think of it as a globally option set in preferences (say per theme for example) for the whole UI, rather than a decision someone would make on a per-use basis.

That could work as well since the meaning of the circle/ring would still be consistent for the user.

> I'd rather think of it as a globally option set in preferences (say per theme for example) for the whole UI, rather than a decision someone would make on a per-use basis. That could work as well since the meaning of the circle/ring would still be consistent for the user.

Harley Acheson commented

2023-07-13 18:05:33 +02:00

For consistency basically. If we decide that progress messages should have ... then we incorporate this in the API. I don't think this should be an option to person using it, but instead part of our core UI guidelines/design.

You mean the ellipsis after "Downloading" in my sample text above? I was asked to make the button text be an optional argument that could be displayed if desired. I selected that sample "Downloading..." as an illustration of its use just because that was used in the request for that argument to be added by Campbell: #109882 (comment)

That said this is hardly a reason to justify more options on the Blender UI. We want the experience for everyone using Blender to be similar, and allowing add-ons (or even the core Blender) to deviate from that can affect this.

I think it likely that Campbell will realize that my "ring" style is better than the "pie" he asked for and we'll end up with just the one small indicator. It is also possible that Campbell imagined this style, and only used the word "pie" loosely as he was talking of a small indicator similar to those used in iOS and elsewhere to indicate download/installation progress

The ring style has become the de facto standard for this type of indicator for a while now. It is this style that is usually used in iOS, MacOS and Windows for this type of indication. Although iOS does use pie-style to indicate app updates over the app's icon. In the mean time his project can use it, rather than waiting for UI polish. Note that this PR was marked as "WIP" when I last worked on it but Campbell wanted it in early for their purposes.

> For consistency basically. If we decide that progress messages should have `...` then we incorporate this in the API. I don't think this should be an option to person using it, but instead part of our core UI guidelines/design. You mean the ellipsis after "Downloading" in my sample text above? I was asked to make the button text be an optional argument that could be displayed if desired. I selected that sample "Downloading..." as an illustration of its use just because that was used in the request for that argument to be added by Campbell: https://projects.blender.org/blender/blender/pulls/109882#issuecomment-976757 > That said this is hardly a reason to justify more options on the Blender UI. We want the experience for everyone using Blender to be similar, and allowing add-ons (or even the core Blender) to deviate from that can affect this. I think it likely that Campbell will realize that my "ring" style is better than the "pie" he asked for and we'll end up with just the one small indicator. It is also possible that Campbell imagined this style, and only used the word "pie" loosely as he was talking of a small indicator similar to those used in iOS and elsewhere to indicate download/installation progress The ring style has become the de facto standard for this type of indicator for a while now. It is this style that is usually used in iOS, MacOS and Windows for this type of indication. Although iOS does use pie-style to indicate app updates over the app's icon. In the mean time his project can use it, rather than waiting for UI polish. Note that this PR was marked as "WIP" when I last worked on it but Campbell wanted it in early for their purposes.

Campbell Barton commented

2023-07-14 01:11:42 +02:00

NOTE: since this PR caused design discussion, we could disable it from RNA until that's resolved. I wasn't expecting this to result in so much discussion, having said this, it seems like only a couple of decisions need to be made.

I'm fine with removing pie-type display (only have BAR / RING).
Manually passing in "50%" for the progress bar isn't great. But this raises the question if it's reasonable to communicate activity in the progress-bar at all. (that a connection is being made, download speed, etc).
I'm wary of the API automatically adding ... to text. We did this for tool-tips (adding a . at the end of every string and it has caused complications as it means Python doc-strings can't use full sentences). For example the text might include a trailing ellipsis (or a unicode ellipsis), which the API needs to strip before adding back the .... So I'd rather make this a convention than an automatic addition.

NOTE: since this PR caused design discussion, we could disable it from RNA until that's resolved. I wasn't expecting this to result in so much discussion, having said this, it seems like only a couple of decisions need to be made. ---- - I'm fine with removing pie-type display (only have BAR / RING). - Manually passing in "50%" for the progress bar isn't great. But this raises the question if it's reasonable to communicate activity in the progress-bar at all. (that a connection is being made, download speed, etc). - I'm wary of the API automatically adding `...` to text. We did this for tool-tips (adding a `.` at the end of every string and it has caused complications as it means Python doc-strings can't use full sentences). For example the text might include a trailing ellipsis (or a unicode ellipsis), which the API needs to strip before adding back the `...`. So I'd rather make this a convention than an automatic addition.

Campbell Barton referenced this issue from a commit

2023-07-15 08:16:28 +02:00

UI: remove recently added PIE progress display type

Campbell Barton commented

2023-07-15 08:25:33 +02:00

Update: removed PIE display type as it seems uncontroversial (only BAR and RING types are now supported).

Update: removed `PIE` display type as it seems uncontroversial (only `BAR` and `RING` types are now supported).

Harley Acheson referenced this pull request

2023-08-13 23:03:00 +02:00

WIP: Indeterminate Progress Indicators #111096