-
Bug
-
Resolution: Unresolved
-
P4
-
21, 24, 25
java.awt.Taskbar specification needs some clarifications.
I see a few things that the java.awt.Taskbar specification doesn't say, perhaps because the author considered them obvious, but they should still be specified
1) An app can call setWindowProgressState to set any of NORMAL/OFF/ERROR/PAUSED/INDETERMINATE
What is the initial state before this is called at all, or if you call setWindowProgressValue(..) without previously setting a state ?
My observation on Windows 11 was that it is probably NORMAL but in one case it might have been OFF ?
2) Is it reasonable to assume that if you set setWindowProgressState to NORMAL without
calling setWindowProgressValue() that the value is always 0 ? Can we be explicit ?
3) The specification for setWindowProgressState says that switching away from INDETERMINATE "may" reset the progress value. If it in fact does, will that mean reset to 0 ? Can we be explicit ?
4) My observation on Windows 11 is that switching away from OFF also resets the value to 0.
Is that just a Windows 11 thing ? Even if it is the same "may" qualification seems to be needed.
5) Does calling setWindowProgressValue with a value 0-100 cancel OFF ? Looks like it may but the spec. just mentions INDETERMINATE.
6) Can we be explicit that if you do not have a value > 0 <= 100 set, that changes of state may not be visible.
eg a PAUSED or ERROR value of 0 may display the same as a NORMAL value of 0.
7) Why are there no getters ?
8) Since there are no getters it might be helpful to remind that the application will have to track the changes it makes and reapply an appropriate progress value that may have been reset. Presumably we don't automatically reapply the last value because it would usually to be wrong to jump back to 90% after an error.
I recommend verifying behaviour on whatever platforms (besides Windows) support the progress aspect of Taskbar, to ensure the spec. are consistent with what those platforms support. This should be based on a solid footing, such as platform API docs at the least and things under our control.
I see a few things that the java.awt.Taskbar specification doesn't say, perhaps because the author considered them obvious, but they should still be specified
1) An app can call setWindowProgressState to set any of NORMAL/OFF/ERROR/PAUSED/INDETERMINATE
What is the initial state before this is called at all, or if you call setWindowProgressValue(..) without previously setting a state ?
My observation on Windows 11 was that it is probably NORMAL but in one case it might have been OFF ?
2) Is it reasonable to assume that if you set setWindowProgressState to NORMAL without
calling setWindowProgressValue() that the value is always 0 ? Can we be explicit ?
3) The specification for setWindowProgressState says that switching away from INDETERMINATE "may" reset the progress value. If it in fact does, will that mean reset to 0 ? Can we be explicit ?
4) My observation on Windows 11 is that switching away from OFF also resets the value to 0.
Is that just a Windows 11 thing ? Even if it is the same "may" qualification seems to be needed.
5) Does calling setWindowProgressValue with a value 0-100 cancel OFF ? Looks like it may but the spec. just mentions INDETERMINATE.
6) Can we be explicit that if you do not have a value > 0 <= 100 set, that changes of state may not be visible.
eg a PAUSED or ERROR value of 0 may display the same as a NORMAL value of 0.
7) Why are there no getters ?
8) Since there are no getters it might be helpful to remind that the application will have to track the changes it makes and reapply an appropriate progress value that may have been reset. Presumably we don't automatically reapply the last value because it would usually to be wrong to jump back to 90% after an error.
I recommend verifying behaviour on whatever platforms (besides Windows) support the progress aspect of Taskbar, to ensure the spec. are consistent with what those platforms support. This should be based on a solid footing, such as platform API docs at the least and things under our control.