-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
qa: Add uiProgressBar tests and fix darwin. #239
base: master
Are you sure you want to change the base?
Conversation
Verify that the indeterminate progress bar animation is properly started/stopped depending on the value set.
uiProgressBarSetValue(-1) will not display a correct indeterminate progress bar animation if a value other than -1 has previously been set. Fixes: qa > uiProgressBar > Progress Bar Indeterminate Start/Stop Animation
Kill the progress bar animation thread to visually display the value change when setting a value [0, 100] when the progress bar is in an indeterminate state. This removes the ~1 second delay that it would otherwise take on macOS 11.7 and possibly other versions.
I can't confirm the issue on my mac. Here are the results. 1. Progress Bar Valuesqa-progressbar-win.mp4qa-progressbar-linux.mp4qa-progressbar-mac.mp42. Progress Bar Indeterminate Start/Stop Animationqa-progressbar-win-2.mp4qa-progressbar-linux-2.mp4qa-progressbar-mac-2.mp4 |
This is a nit but I noticed $ git -c 'core.whitespace=trailing-space,space-before-tab,indent-with-non-tab,tabwidth=2' --no-pager diff --check origin/master
test/qa/entry.c:156: new blank line at EOF.
test/qa/progressbar.c:91: new blank line at EOF. And the message for |
I also noticed the moving progressbar stops its animation when resizing the parent window on Ubuntu 20.04. qa-progressbar-linux-resize.mp4 |
Two visual tests for uiProgressBar.
The second one fails on my system: macOS 11.7 (Big Sur) . Setting
-1
after previously having set some other value will not return to the expected moving bar animation as before but flash the last value in a weird way.The third patch in this series fixes this by calling
[p->pi displayIfNeeded];
.Another thing that seems to work is calling
[p->pi setUsesThreadedAnimation:NO];
and[p->pi setUsesThreadedAnimation:YES];
but I found this to be cleaner.Another possible issue that
qa > uiProgressBar > 2.
highlights is the delay when setting a value on darwin whilst the progress bar is animating.I was able to get an instant set by encapsulating thesetIndeterminate
call. Happy to include that in this patch set.Edit: I included the patch to stop the animation instantly (by killing the thread) and set the new value without the (~1 second) delay I was experiencing on my system.
I also added an early return when setting
-1
when we are already animating to match unix and windows. Good old defensive programming.