Since both the spinfinity progress bar and text
progress bar are very similiar, it makes sense
to export parallel api for them. This just changes
things around a bit so that the two plugins and
controls more closely model each other.
This change also takes advantage of the on_boot_progress
plugin interface to get more reliable boot timing
information.
This way all plugins can access it as a standard feature.
We'll need to move it a layer higher still, though, to
make sure progress bars don't get reset when the user
presses escape twice, etc (it's per-boot state, not
per-splash state).
The progress bar uses an estimate of boot time - defaulting to
45 seconds if unknown - and runs from 0% to 100% over that
interval.
The patch measures how long it takes to boot and writes that
value to /var/lib/boottime at plugin shutdown. (This is kind of
a nice side-effect - we get actual *measured* boot speed data,
rather than just "feels snappier!")
There's an associated script, update-boottime, that crams
/var/lib/boottime into your initrd, so this splash plugin can
use *that* to more closely approximate the time required to
boot.
This is similar to the OS X "WaitingForLoginWindow" process -
see
http://daringfireball.net/misc/2005/04/tiger_details#waitingforloginwindow
for details on that.
It's an effective placebo - startup *seems* faster with the
progress bar, even though it's exactly the same.
You can enable it by adding 'timebar:1' to the boot commandline.
This will make it run in linear-time mode - the progress bar
moves linearly from 0% to 100%.
Using 'timebar:2' modifies the percentage calculation to use an
exponential function - this makes the bar run faster at first,
then slow as it approaches 100%. This makes startup seem even
faster.
I was a little quick to the trigger in the
previous commit. This commit fixes the build
by passing in the right arguments to the function
and also clears out a duplicated chunk of code.
We always want to hide the text splash when plymouth
quits. Even if --retain-splash was called. Cross
fading from text to graphics doesn't make too much
sense.
There are times when we want to make the splash
screen stop any pending animations and got to an
idle state. For instance, right before resuming,
or right before loading up GDM. It may take a
few frames for the splash screen to get there though.
This interface tells the splash screen it needs to
idle and provides a trigger for it to fire when it's
actually made it to an idle state.
This just calls a closure at a later point in time.
It will get used for having the splash plugin perform
tasks that will make the daemon defer responding to
the client.
We basically don't want to ever implicitly hide on
the shutdown path, only when asked to explictly,
or when the splash plugin itself deems it
necessary.
