a bunch of lines are shorter or different length now which
triggers a mandatory reformat. this patch cleans that up,
so that going forward the manual rework patches are clearer and
not tied up with formatting patches.
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.
- 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.
- 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.
A Chat object provides a generic UI to read a series of Posts in a Dialogue stored in the pddb - and to Author a new Post.
The idea is to provide a solid common Xous Chat interface, so that Chat Apps can specialize in the unique aspects of a chat Platform protocol (Matrix, Signal etc).
A Chat App will typically call `Chat::new()` and then `Chat::dialogue_set()` with a pddb dict and key holding a Dialogue of Posts. The Chat object will fire-up the UI and retrieve the Dialogue from the pddb. The user will be able to peruse the stored Posts in the Dialogue - and potentially Author a new Post. A new User Post will be sent to the Chat App in a `MemoryMessage` via the (optional) `CID` and `Opcode` provided by the Chat App. Conversely, when the Chat App receives a new Post from the Platform, it will call Chat::post_add() to have it saved in the pddb.
The Chat UI will also accept (optional) opcodes to forward raw-keystrokes and UI-Events to the Chat App. This allows the Chat App to respond to key UI Events. For example if the User navigates to the `top` of the list of stored Posts, then the Chat App might retrieve older Posts from the Platform to be stored Dialogue with calls to Chat::post_add().
