This has to be one of the more pointless things I've ever put time into understanding. Since the time has already been invested, however, I figured I might as well share what I've learned.
In the CM7 Nightlies thread, we've recently been talking about custom "all-in-one" zips that people create to flash after any Nightly install. As I was looking through various scripts (both in the thread and elsewhere on the forum), I noticed an inconsistent syntax being used for the show_progress command.
If you've ever flashed a zip and watched your progress bar fill up so far that it goes off the right side of your screen, chances are that the zip had the wrong syntax.
A lot of scripts that I've seen are using:
show_progress(duration,fraction)
fraction = a fraction of the bar (more on that in a moment)
duration = seconds
But the correct usage is:
show_progress(fraction,duration)
fraction = a fraction of the bar (more on that in a moment)
duration = seconds
The "seconds" part just means how long the progress bar should take to fill up to the new level. It will not delay your script in any way: it will only take this much time if something else in the script is also taking that much time.
For example, if you run this snippet, you can watch the progress bar partially fill up pieces at a time. Each piece will take 5 seconds to fill, then pause for 2 seconds before the next piece starts (sleep command is for 7, so after the progress bar is done its 5 seconds of movement, there are 2 seconds of sleep left until the next command)
In this snippet, I've removed the sleep commands:
Now the progress bar will instantly jump and then the script will immediately end. Even though each chunk was supposed to gradually fill up over 5 seconds, nothing in the script allowed it to actually run for that long.
Note also that the fractions are cumulative. I've seen a lot of scripts that use the show_progress command but have 10%/20%/30%/40% arguments built in. They seem to assume this means that each command is setting the progress bar that new value, but that is not the case. Instead, that means that they are starting at 0 and adding 10. Then adding 20 to 10. Then adding 30 to the existing 30. Then adding 40 to the existing 60... you get the idea.
Regarding the fraction part of the command, I had assumed that 0 meant 0%, 0.5 was 50%, 1 was 100%. In my testing, however, that has not been the case.
For example, I tried the following:
I expected that the progress bar would fill up to 100% over the course of 15 seconds. Instead, it only filled up about 75%
I kept testing until I found what visually makes my progress bar look actually full: 1.34
So if I want to watch the progress bar fill from 0% - 100% over the course of 10 seconds, I would use:
I have no idea why that's the magic value, but it's repeatable on my device. Please try on your own Incredible and let me know if you see the same. I'm using CWM 3.x for whatever it's worth. It wouldn't surprise me if this was different in other versions of CWM, but I don't know.
As an example of what I've seen, here are some lines from a popular kernel's script (I am only copying the show_progress lines)
It looks like the script author was trying to make the progress bar fill up in increments of 10, with a 0.5 second delay. What is actually being done by these lines, however, is to keep adding 0.5 (which works out to roughly 37% of 1.34) to the progress bar.
In other words, these commands will fill up the progress bar as follows:
0% > 37% > 75% > 112% > 149% > 187% > 224% > 261% > 299% > 336% > 373%
If the progress commands had enough time, this would also mean that each chunk would fill at a slower pace (since the duration is increasing), but the script moves fast enough that the user never sees this.
None of this actually changes the functionality of the script, hence my earlier declaration that this was somewhat pointless to learn. This is strictly an aesthetic issue for the user, but if you are going to write scripts, I hope this comes in handy.
In the CM7 Nightlies thread, we've recently been talking about custom "all-in-one" zips that people create to flash after any Nightly install. As I was looking through various scripts (both in the thread and elsewhere on the forum), I noticed an inconsistent syntax being used for the show_progress command.
If you've ever flashed a zip and watched your progress bar fill up so far that it goes off the right side of your screen, chances are that the zip had the wrong syntax.
A lot of scripts that I've seen are using:
show_progress(duration,fraction)
fraction = a fraction of the bar (more on that in a moment)
duration = seconds
But the correct usage is:
show_progress(fraction,duration)
fraction = a fraction of the bar (more on that in a moment)
duration = seconds
The "seconds" part just means how long the progress bar should take to fill up to the new level. It will not delay your script in any way: it will only take this much time if something else in the script is also taking that much time.
For example, if you run this snippet, you can watch the progress bar partially fill up pieces at a time. Each piece will take 5 seconds to fill, then pause for 2 seconds before the next piece starts (sleep command is for 7, so after the progress bar is done its 5 seconds of movement, there are 2 seconds of sleep left until the next command)
Code:
show_progress(0.2,5);
sleep(7);
show_progress(0.2,5);
sleep(7);
show_progress(0.2,5);
sleep(7);
Code:
show_progress(0.2,5);
show_progress(0.2,5);
show_progress(0.2,5);Note also that the fractions are cumulative. I've seen a lot of scripts that use the show_progress command but have 10%/20%/30%/40% arguments built in. They seem to assume this means that each command is setting the progress bar that new value, but that is not the case. Instead, that means that they are starting at 0 and adding 10. Then adding 20 to 10. Then adding 30 to the existing 30. Then adding 40 to the existing 60... you get the idea.
Regarding the fraction part of the command, I had assumed that 0 meant 0%, 0.5 was 50%, 1 was 100%. In my testing, however, that has not been the case.
For example, I tried the following:
Code:
show_progress(1,15);
sleep(20);I kept testing until I found what visually makes my progress bar look actually full: 1.34
So if I want to watch the progress bar fill from 0% - 100% over the course of 10 seconds, I would use:
Code:
show_progress(1.34,10);As an example of what I've seen, here are some lines from a popular kernel's script (I am only copying the show_progress lines)
Code:
show_progress(0.500000, 10);
show_progress(0.500000, 20);
show_progress(0.500000, 40);
show_progress(0.500000, 60);
show_progress(0.500000, 70);
show_progress(0.500000, 80);
show_progress(0.500000, 90);
show_progress(0.500000, 100);In other words, these commands will fill up the progress bar as follows:
0% > 37% > 75% > 112% > 149% > 187% > 224% > 261% > 299% > 336% > 373%
If the progress commands had enough time, this would also mean that each chunk would fill at a slower pace (since the duration is increasing), but the script moves fast enough that the user never sees this.
None of this actually changes the functionality of the script, hence my earlier declaration that this was somewhat pointless to learn. This is strictly an aesthetic issue for the user, but if you are going to write scripts, I hope this comes in handy.
