This commit adds explicit selection knobs for all possible
types of characters and symbols.
A side effect is there is also now an error loop to handle the
case that none of the knobs are selected. The user cannot
proceed with generation until at least one type is selected.
When no alphabetic characters are selected, "exclude similar" is
now false, which allows all of the numbers to be picked from.
Normally, 1, 0, etc. are avoided to make it easier for humans
to read/copy the passwords without ambiguity. This does reduce
the total entropy slightly, but ideally you are using the
password generator with a long setting (20 or so characters)
so you're well beyond the worry of losing entropy due to dropping
the few similar characters.
- 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.
