- 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.
`EXPECTED_APP_CONTEXTS' was added to the list of authorized
switchers. I don't think this is ideal, but I think it would be
difficult to come up with a better solution that doesn't make
`app-loader' "special" in some way.
This allows `app-loader' to register new names (which are then used by
the loaded apps to claim tokens). At the moment this is restricted to
apps that are pre-registered, i.e. included in the image.
I decided to go back on the idea of not changing the modals
and now all modals use the new larger font as well.
This creates issue #396, which I will deal with later once
I have the time to do some more testing. I'm pretty sure
some other dialog boxes are broken now too.
default system font can be statically changed by modifying
the SYSTEM_STYLE constant.
This of course will lead to a request for a dynamically
configurable preference for font size. However, early
on it was decided this is a bad idea. Here's why.
We don't provide for dynamic system-wide font selection
because this adds a lot of complexity to what would otherwise
be static code: this is a deliberate choice to improve code
density and performance. If the system font were dynamically
adjustable, then every character rendered we would potentially
have to query the PDDB for the current system font setting.
The impact of this could be mitigated by caching values but
then what happens when you actually change the font? now
you need a registry to fire messages off to all dependent
crates with cached values to flush their caches and redraw
(or you punt and force a reboot if you change font sizes,
but still, you're creating a dependency on a lot of plumbing
for even the simplest crates).
Plus, with a static font selection, the compiler can take constants
like the font height and compose them with other fitting
parameters into optimized load/stores of borders and spacings
for the static case; if you make it dynamic, all those multiplies,
adds and divides now get pulled into the main rendering loop
and are recomputed all the time. For example, if you have a static
const list of items that need to be rendered, even if the code to
compute the height of the list is written as a for loop, the compiler
will know the list is constant, and the font height is constant,
and it can condense that all into a single number at compile time,
eliminating all the code for the for loop.
If you leave the option open to change that, that entire piece
of code has to be generated and executed even though in practice
nobody changes the parameter.
This change is made with the intention of making the xous-rs crate a bit
more freestanding without depending on the xtask build system.
Signed-off-by: Jean-Pierre De Jesus DIAZ <me@jeandudey.tech>
- make the "base" field no longer public. It is accessible, but only
through an `unsafe` method, because, it is unsafe.
- add accessors to offest/mask fields. Because, it's not at all
unsafe to access these, and it can be useful for bit-ops that are
not part of the generic set of UTRA.
- add Arc to AtomicCSR, and require `std` for AtomicCSR types.
This should not break anything, I checked inside @foundation-devices
keyOS and they don't seem to be using AtomicCSR anywhere.
The Arc makes it a bit safer to clone the AtomicCSR base pointer
and share it between threads, but it will have an impact on performance.
The USB stack (which requires AtomicCSR) was regression testing and the
impact seems minimal.
Recall that the main purpose of AtomicCSR is to provide a CSR accessor
that does not require a mutable reference to the base object. This
can make certain Rust idioms a bit cleaner. We wrap the base accessor
in Arc+Atomic to try and improve the safety of throwing the borrow
checker under the bus, but it's still not perfect because hardware
mutable state can have side-effects within hardware itself that cannot
be modeled or checked by Rust's borrow checker.
this is some bit-rot that happened to the `ball` demo because
it's currently the only application that uses the framebuffer
canvas.
the trust level of the framebuffer canvas has to be lower than
that of the modals, otherwise a modals box is not allowed to
draw on top of the framebuffer.
in this case, a patch that was applied when trust levels were
refactored was missed on the framebuffer canvas, which caused
the trust level of the canvas to be higher than that of a modals.
Thus, when a modal attempts to pop up over the ball demo,
one just sees the defacement lines but no actal content.
TextEntry boxes can now specify "growable" as an option; if this
is set true, then, the fields within are considered to be multi-line
fields that can grow to fill the screen (even pushing lower ui
elements off the screen...); however a text line is limited to
256 characters so generally the overflow issue is hopefully rare-ish.
Left/right arrow keys conjure up an insertion point to allow for
deleting and inserting text in the middle of a field.
The main quirk is that if you enter text that causes a field to grow in
size, the overall dialog box can't grow any larger, so the text simply
overflows into the UI element above the current line, without limit.
Need to check for interactions with other elements that should
not be affected but it passes some simple test cases in `vault`.
