This is the weirdest damn thing. All the crates say 0.4.19 as
the chrono version, but the actual version in the lockfile
is 0.4.33. And there isn't an error about it?
Anyways, this update the pins to reflect what's in the lockfile.
looks like about 9 crates will be affected by this. Point them
all to the latest version of the API, and specify the
"precursor" feature (which activates our patch)
rustfmt shortened some blocks to be one-liners.
the blocks ensure the contents have Drop called on them.
the linter hates the braces, saying they are unused.
Perhaps, in fact, the contents don't need Drop called
on them exactly at that time because there isn't a conflicting
statement elsewhere in the block that uses it. It *might*
be right.
But then, later on, when you write some code that assumes
that implicit Drop happened, guess what. You'll spend hours
scratching your head as to what went wrong.
I just stuck a comment in the block to keep rustfmt from
thinking it should format that block.
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.
