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.
when the font menu is raised while in TOTP mode, the "pump"
thread continues to prompt for redraws, which can eventually lead to
an overflow of the server queue on the main thread that leads to
deadlock and eventually a crash.
This patch does two things:
- splits the allow_host variable and the allow_totp_rendering variable
so that the two flags have distinct meanings
- use the allow_totp_rendering variable to control when the
totp thread is allowed to pump the main thread to animate the
timer bar.
Previously the allow_host variable was introduced to control access
to sensitive data, and it incidentally was also used to control
TOTP rendering because when host readout is activated this can
freeze the UI for extended periods of time.
By splitting the flag we can now control both independently of
each other. Rendering still stops when host readout is enabled,
but it also stops when any other blocking dialog boxes are popped up,
hopefully preventing future crashes if a user is distracted in
the middle of a UX flow that can block the main loop.
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>
rely more on the cache retaining consistency with the disk
versus always reloading from the disk to speed up performance.
might be useful to make a routine that can also check coherency
periodically, because with the new format the cache could
co-exist along side the database for a very long time without
any checking.
also eliminates references, copying and locking of items in the
sorted btreemap.
turns out that ... sorting is much cheaper than copying or maintaining
references, because copies to heap items require allocs which are
under the hoood several sorts to find the place to stick the alloc
memory, and shared references require locks.
- 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.
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`.
If the "notes" field starts with the characters
"bip39" (case insensitive), then, the password field is
interpreted as a hexadecimal encoding of BIP39 entropy.
To create a BIP-39 entry, leave the password field blank,
and then start the Notes field with the characters 'bip39',
and this will trigger a dialog box that will only allow
valid bip39 entry and check the checksum etc.
To view the BIP-39, after opening up the entry for "edit",
close it, and it will pop up a second dialog box that interprets
the hex data as BIP-39 words.
You could also in theory enter the hex digits yourself into
the password field, if you're masochist.
The crate just re-exports the com_rs crate. This patch changes usages of
com_rs-ref to use com_rs directly.
Signed-off-by: Jean-Pierre De Jesus DIAZ <me@jeandudey.tech>
