the scroll-down freeze is actually because of the nature of
the test program hijacking the main loop. the test program
probably needs to be redesigned so it takes in events so we
don't eventually end up in deadlock
this is computed when the post is added to the list of posts.
Also split out the visual properties of a UI into a separate
struct so that we can pass it as a single argument to routines
that could handle layout-related tasks.
- the `post_add()` API on the 'lib' side of things says Add a new Post
to the current `Dialogue`, and it passes an empty `dialogue_id` string.
- the `post_add()` handler on the server dutifully unpacks the `dialog_id`
field with `post.dialogue_id.as_str().unwrap()`, and then passes on to
the `post_add()` call inside the UI object
- the `post_add()` implementation in the UI object then checks the
`dialog_id` with if `pddb_key.eq(&dialogue_id)`, expecting that the key
should match the dialog id. But through this path, the dialogue ID
is always the empty string, so the function can't work.
This patch causes the code to "fall through" and use the default
`pddb_key` if the length of the `dialog_id` is zero. Not sure if
this is the intended behavior, but in the test case at least I get
posts appearing now once this patch is in.
- rapid redraws are normally aborted by this routine. offer a forced
redraw in the case that a "final state" has to be rendered without
fail.
- fix a misdirected message (sending it to app instead of to ui by
accident)
this simplifies the problem of tracking concurrency if multiple threads
are requesting a busy-state to be presented. In this case, when the
final thread leaves its busy state, the idle-state will be shown.
- remove modal pop-up for wifi connection, and replace with
busy animation
- specify units of delay in the constants (_MS to indicate milliseconds;
this is a convention I'm trying to adhere to)
- partial progress on debugging why the animation isn't running
(value of animation variable is not being passed back at the GAM layer).
Also a general note on coding styles that probably is going to cause
confusion now that more people are contributing to the code base.
Generally, when a lot of "generic" library functions fail, we've been
passing an error message up the stack. However, these functions are
actually meant to be infalliable, and when you kick the error up the
stack you just end up with a panic at an unhelpful location (because
you finally catch the error only at the main loop or something and
by that point there's nothing you can really do about it but panic,
since it's supposed to be an infalliable operation).
As a result I have been trying to tamp down on needless error propagations
and having them fail with a unwrap or expect at the point where the
abstraction should be infalliable. This helps in debugging the actual
failure root cause because you're closer to the line of code that
actually broke, instead of just some line at a generic error handler.
Of course if you build with stack unwinding the top-level unwraps are more
useful because you can peer down into the call chain, but even then,
with the limited screen real estate I think deeply nested failures
would probably overflow any panic display. So even with panic unwinding
I think we stil want to keep the root cause within a few stack frames,
instead of errors being passed up sixteen levels of abstraction before
finally dying.
This only applies to things that are meant to be truly infalliable,
like syscalls that should not fail, or like unpacking a buffer or
memory message that has already been allocated. In this case the errors
are more like asserts, and are helpful if they fail at the line where
they break instead of being passed up the call stack (which was the
original architecture).
Probably I should add a note about this to the Xous Book.
- 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.
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.
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
This is necessary because mounting the PDDB is a "secure" operation, and secure ops will fail until all UX contexts are occupied.
This problem does not manifest in hosted mode because we cheat and automount the PDDB in hosted mode.
this case is too sensitive to clock config outside of the PIO
block, because it relies on some specificts of how inter-bus sync
works and the environment is free to set PIO and PCLK relationship
arbitrarily
