This commit adds `modals::Modals::slider()` with the same interface as
`modals::Modals::start_progress()`, with the striking difference that
users can move the slider, and press the center keypad button to confirm
the selection.
Useful for objects like audio volume controls.
This refactors the remaining vault accessor routines to use
the new more efficient key pre-fetching routine. This also
fixes up an error in test case generation and hopefully resolves
an issue with concurrency errors using the older version of
the access routine.
This bug was hidden by the previous return of state before
the reliquish.
Now with the correct ordering, we end up getting a double-relinquish
which ends up trying to swap a modal into focus which doesn't exist.
This fixes that edge case
This call can be used by clients to try connecting to a service. If the
service is not available, this will fail to connect.
Signed-off-by: Sean Cross <sean@xobs.io>
mount initiator is now back inside of the status thread
(woo, no more app-specific dependency) and there is now a
wait on "attempted to mount" inside the status thread which is
the signal to clear the "waiting on boot" message.
this is to allow a UX process to clear the "waiting for boot"
indicator once an attempt has completed.
right now, it responds *after* the mount process is done,
so the "please waiting" text persists even doing a format.
I think that is...appropriate?
While it's a kind of neat effect to have the "please wait"
message persist right up until the point where the dialog box
pops up, the problem is that the blit of the backplane captures
that, so when the context is reverted that message is still there.
On a very fast mount (empty PDDB under Renode emulation) the
mounting call finishes so quickly that the dialog box that would
normally trigger the redraw to clear this message never renders.
This patch forces the screen to blank before trying to call
PDDB init, ensuring that we don't have that persist after the
mount, even if it is very fast.
The downside is there is a fraction of a second where the please
wait disappears, and the dialog box pops up. That is just the
time it takes for the system to setup for the cryptographic
operations.
This refactor (at least partially) fixes a "mystery delay"
sometimes required after a dialog box swaps out. The previous
implementation would send the response, and then swap the contexts.
This would often cause the recipient to start drawing its UX
before the calling app was foregrounded, causing elements to go
missing.
This refactor puts the response after the context swap. The main
downside is it requires every type of modal to have a GAM
handle to issue the redraw call, and is especially complicated
by the fact that GAM is not clone-friendly. However, the
trade-offs of either creating a handle dynamically or storing
one in the object is probably worth the benefit of removing
an open-loop delay.
There's a race condition between the return of a blocking scalar
and when focus is relinquished.
This causes chained graphics operations to get dropped sometimes.
Move the return result to after the focus switch; this allows us
to elimate some dead waits.
The initial wait message is drawn directly under where
the modals would appear, so the message "goes away"
when modals pop up.
There's still a bit of trickiness around the timing of
some of the calls. Attempting to mount the PDDB too early
before all the contexts have been registered leads to
a lot of needless defacing.
Also, the final redraw needs a short delay to allow
the system to foreground shellchat again after closing
the modals.
- remove a blanking operation. this makes the transision from
loader to runtime almost imperceptably smoother
- add the ability to summon the logo screen earlier in the process
Note that only GAM can call GFX, so, it's alright to expose that
API, since GAM should gate-keep and prevent abuse of that function.
The initial wait message is now rendered by the first app
that owns the screen (currently shellchat).
The location where the pop-up modal is rendered is also now bracketed
directly around the mount call to avoid interference with other
edge cases that may pop up modals.
it's now in shellchat. In general, the program that is assigned
as the initial app context is responsible for ensuring the
PDDB is mounted. Thus, if `vault` were to become a stand-alone app,
it should include some code to make sure the PDDB is mounted as
part of its boot sequence.
The reason is that it allows the initial app to guide the
power-on experience, instead of delegating this to the `status`
bar, which is oblivious to the state of the app.
