- status bar text is just status bar text now
- idle animation runs/stops based on an explicit run/stop message
Note that at the moment if one starts the busy bar and a modal pops
up, you might overflow the queue of the ui drawing thread with animation
requests, because the thread blocks when the modal is summoned.
Modals "take the screen" anyways, so maybe the solution to this is
to add an additional interlock around any modal calls within the UI
main thread. Need to think about it a bit more.
XOR op should not be usable to create fake security boxes
but it also looks really ugly to have it defaced.
This small tweak makes the XOR function look decent for the initial
purpose of the function (chat status bar wait indicator).
Eventually, this will be a controversial decision, but I'll kick
that down the road.
Busy-wait animaitions are handled by a helper server that is normally
blocked. A single shared `bool` indicates whether the animation should
run or not.
When woken up, the busy-wait animator will check if the shared `bool`
is set, and if so, send a message to the main loop to update
the animation, then send wait an appropriate timeout and send itself
a message to re-check the animation status.
This particular format of server is fairly compact but can be vulnerable
to a "message storm" if busy state updates happen in rapid
succession without allowing the server to unblock and handle messages.
Thus, all messages to this server use a `try_send` method, with a silent
failure if the message can't be sent. In other words, if the animator
is already super busy and its queue is full, don't send it more messages,
just drop the existing updates so we can fail without a panic or deadlock.
The typical consequence of this is some UX inconsistency, which is
not a critical error.
- status bar gets some initial text on boot
- previous status message is saved when entering a busy state,
and restored on exit
- add routines for hopefully making the redraw a bit more efficient
if the only thing happening is a busy-wait update.
this it to avoid abusing the primitive to create inverted text
(for secure UI elements only). It does degrade from the aesthetics
of a busy bar but it is a computationally efficient way to patch
around the concern.
This is just the TextView primitive with a "state" variable added
that controls how far the strips should march across the screen.
Users can specify with or without a bounding box.
The exact location of the text within the bar depends on the
BoundingBox option picked.
The primitive computes the total region to animate based upon
the typesetting engine's output. Thus it is not recommended
to "compress" the amount of whitespace allocated to the animation,
because it can cause the animation to have artifacts due to
whitespace overflow of typesetting.
unwrap on a routine always returns None, so the unwrap() has no meaning
(probably originally introduced just as a way to get match arms to
have the same return result without thinking too much about it).
Every entry into the sleep_heap() should be unique. Any insert()
call that returns a value means we're going to drop a wake-up event.
Add an assert()! that will trigger a panic if this invariant is not
met.
Add back in the ability to pre-unlock a Mutex. This is used for slow
path unlocking without needing to wait for a response.
Signed-off-by: Sean Cross <sean@xobs.io>
This rewrites the Mutex and Condvar backends after gaining a better
understanding of how they're supposed to work.
Additionally, the Ticktimer backend implementation has changed:
* There is now a `recalculate_sleep_offline()` call that skips starting
and stopping the ticktimer. This is an unsafe function because the
user must manually manage the ticktimer state. It is used to perform
multiple operations while the ticktimer is unscheduled.
* Ticktimers now deal in `TimerRequest` types rather than raw `i64`
types. This is a newtype that is distinct from the previous `i64`, but
should behave largely the same.
* Waking a Condvar now reports the number of items that were awoken,
provided the requester sends a blocking scalar value. This allows for
backwards compatibility.
* Attempting to wake 0 Condvars now wakes all pending Condvars.
* We no longer keep track of lock-then-unlock for Mutexes, nor
notify-then-wait for Condvars. This makes those cases undefined
behavior, which puts us in line with Posix. Don't unlock mutexes that
haven't been locked, or notify Condvar recipients when nobody is
waiting.
Signed-off-by: Sean Cross <sean@xobs.io>
panics happen due to certain default states of the EC
wire protocol, due to a MAC address being passed in that is
not unicast when garbage data is present.
this needs to stabilize once they tag out a release but for now
it cleans up the warnings.
will have to remember to do a cargo updae on that repository though
from time to time to get the latest code...
Set up tls with rustls::ClientConnection,
BUT - on Error::InvalidCertificate - then
probe the host for the untrusted certificate chain and prompt the user
to perhaps trust one of the certificates in the chain - then try again.
- add duart debug for bare iron testing
- add wait states on FIFO commits for when CPU clock is much
faster than PIO clock.
more wait states will be needed for correct operation in the
future
