stage-1: Add progress tracking in splash #233
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
samueldr
commented
Oct 27, 2020
samueldr
force-pushed
the
feature/stage-1-progress
branch
2 times, most recently
from
3ed6343
to
172b6e7
Compare
samueldr
added
3. topic: stage-1
samueldr
force-pushed
the
feature/stage-1-progress
branch
from
172b6e7
to
785fcab
Compare
This gives us a better idea, relatively, when things happen to be logged.
This is to ensure "UX-friendly" tasks gets run ASAP. Quickly explained, this makes sure that the top tasks (e.g. Splash) gets ran as soon as possible. Given the list: - Splash - Graphics - AAA - BBB - CCC If `Graphics` ends up running, and AAA, BBB and CCC can too, Splash will have to wait until all those tasks got ran once! Not ideal for UX, if e.g. BBB takes time to *run* and we can't show the progress to users! The added cost of restarting the queue is minimal with tests I ran. It was not more than a tenth of a second, and could even be rounding errors.
This will be used by the upcoming progress-tracking feature.
The applet is specifically written to show what we call the "recovery menu". Yes, it's also the boot selection, but it will get confusing with the upcoming boot tracking splash UI that's upcoming.
samueldr
force-pushed
the
feature/stage-1-progress
branch
from
785fcab
to
6ecb2ae
Compare
The splash is now an application that should be started and forked from.
Once started, it will listen for messages on a ZeroMQ socket reporting
progress.
The current protocol is extremely simple, reporting (optional) label,
and reporting a progress amount.
Additionally, it responds to a string commant ("quit") to quit as
needed.
samueldr
force-pushed
the
feature/stage-1-progress
branch
from
6ecb2ae
to
a50f838
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds a progress bar to stage-1 loading:
It is a "proper" GUI to show the status of the boot. Right now tasks that have opted-in will show a label while they are working. This may be useful for e.g. resizing a filesystem.
In a future update, already planned, dependencies that are "hung", or "seemingly not resolving" are going to end up showing up on that, too. When that future update lands, not having a filesystem to mount will be quite obvious.
There is one big caveat: display initialization happens so late that we often are at 80+% of the tasks done. That means that for many devices the splash looks a bit dumb.
Ideally, we would figure out why it takes so long to get the display init going.
Though maybe we want to instead not show a progress bar, but something more indefinite? Then add messages when relevant? Or maybe always print the task that just finished, so you get a flurry of text changing!
Tasks