Details
-
Type:
Improvement
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 4.1
-
Component/s: ACE-Components
-
Labels:None
-
Environment:ICEfaces 4 ace:progressBar
-
Assignee Priority:P1
-
Support Case References:Support Case #12807 - https://icesoft.my.salesforce.com/5007000000c2f8n
-
Affects:Documentation (User Guide, Ref. Guide, etc.), Sample App./Tutorial
Description
It would be useful if the ace:progressBar could support an "indeterminate" mode, like the ice:outputProgress component does, for use when the application wants to show a busy state, but the task completion is not knowable in terms of steps or percentage complete.
When in "indeterminate='true'" mode, the progress bar would show a constant animation across the entire span of the bar when active to show that it is in a busy or active state.
When in "indeterminate='true'" mode, the progress bar would show a constant animation across the entire span of the bar when active to show that it is in a busy or active state.
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
r46012: added missing IDs to checkboxes; rearranged position of checkbox to avoid positioning issue of the reset button.
This fix solves issues #1 and #3 above.
As for #2, that's the correct behaviour, according to the rules listed above. If when paused we cleared the progressbar, it would seem like the progress was cancelled. If we filled the progressbar, then it would seem like it already completed. Filling part of the progress bar doesn't apply, because when in indeterminate mode, the progress is not supposed to be measurable in terms of percentages or steps.
Show
Arturo Zambrano
added a comment - r46012: added missing IDs to checkboxes; rearranged position of checkbox to avoid positioning issue of the reset button.
This fix solves issues #1 and #3 above.
As for #2, that's the correct behaviour, according to the rules listed above. If when paused we cleared the progressbar, it would seem like the progress was cancelled. If we filled the progressbar, then it would seem like it already completed. Filling part of the progress bar doesn't apply, because when in indeterminate mode, the progress is not supposed to be measurable in terms of percentages or steps.
Some important notes:
- It was necessary to update all the themes to be able to display the animation. This means that any app developers who are using a custom Themeroller theme will have to update their theme to include the progressbar overlay for the indeterminate mode, since it didn't exist in previous versions.
- The indeterminate feature works as a mode in our component, but it works as a state in the underlying jQuery widget. This means that by setting indeterminate="true" the progressbar doesn't show the indeterminate animation right away but only when the progress is started. In the underlying widget, setting value=false immediately starts the indeterminate animation. So, this required some new, albeit intuitive, rules for our component, which are the following:
1) When indeterminate="true", if the value of the component is 0, the progressbar is displayed empty.
2) When indeterminate="true", if the value of the component is > 0 and < 100, the progressbar shows the indeterminate animation.
3) When indeterminate="true", if the value of the component is 100, the progressbar is displayed as full or complete.
Show
Arturo Zambrano
added a comment - Some important notes:
It was necessary to update all the themes to be able to display the animation. This means that any app developers who are using a custom Themeroller theme will have to update their theme to include the progressbar overlay for the indeterminate mode, since it didn't exist in previous versions.
The indeterminate feature works as a mode in our component, but it works as a state in the underlying jQuery widget. This means that by setting indeterminate="true" the progressbar doesn't show the indeterminate animation right away but only when the progress is started. In the underlying widget, setting value=false immediately starts the indeterminate animation. So, this required some new, albeit intuitive, rules for our component, which are the following:
1) When indeterminate="true", if the value of the component is 0, the progressbar is displayed empty.
2) When indeterminate="true", if the value of the component is > 0 and < 100, the progressbar shows the indeterminate animation.
3) When indeterminate="true", if the value of the component is 100, the progressbar is displayed as full or complete.
r45999: added indeterminate mode option to showcase demos
Show
Arturo Zambrano
added a comment - r45999: added indeterminate mode option to showcase demos
r45998: updated all themes to include the progressbar overlay for the indeterminate state
Show
Arturo Zambrano
added a comment - r45998: updated all themes to include the progressbar overlay for the indeterminate state
r45996: updated jQuery UI Progressbar plugin to version 1.11.4, which supports the indeterminate state; added indeterminate attribute to ace:progressBar; added logic to the ace:progressBar component to work in an indeterminate mode, both in the server and client side.
Show
Arturo Zambrano
added a comment - r45996: updated jQuery UI Progressbar plugin to version 1.11.4, which supports the indeterminate state; added indeterminate attribute to ace:progressBar; added logic to the ace:progressBar component to work in an indeterminate mode, both in the server and client side.
Verified ICEfaces 4 trunk r46015, Tomcat 7, IE 11, 10, 9, 8, FF 34, Chrome 45.