change the notification modal to accept the primary message and an
Option of independent text to display as a qrcode
pub fn show_notification(&self, notification: &str, qrtext:Option<&str>) -> Result<(), xous::Error> {}
This is a start on issue #111, where instead of starting a throw-away
server and doing a "yield" loop to emulate blocking behavior, messages
are instead stored so they don't drop, thus keeping a blocking
message blocking.
This call was originally part of the RTC driver, but when we
refactored things out, this was forgotten.
So, what would happen is, if you did a coldboot or reboot,
an alarm would get set and...well, the way the RTC blocks
is it'll keep asserting the alarm until you clear it.
This prevents the system from sleeping, and also keeps
the CPU pegged at 100% for some reason. The prevention
from sleeping makes sense to me. The CPU at 100% probably
indicates there's a problem in the event router, but
this path isn't used for anything at the moment so
we'll just open an issue and leave it as technical debt.
modals don't work when triggered in the status thread in hosted
mode (but they do, somehow, on real hardware). I think this
is an actual locking problem that would exhibit itself if
we had a true multiprocessor system, but since real hardware
is a single processor it doesn't show.
now you set time in local time. If time zone hasn't been set already,
it'll prompt you to enter a time zone.
The main oddity is now that you have to know your time zone as
an offset from UTC. This can be fixed later with a proper symbolic
TZ to numeric mapping, but, that's actually a surprisingly hard
feature to implement.
Time is replaced with error messages that indicate either time has not
been set ("Set Time"), or the PDDB has not been mounted (it says
"Login?"), if there is an error. otherwise it displays time
in the local timezone.
Time setting is kind of awful in that you have to enter the time
as UTC. And then a timezone as an offset in hours from UTC. It's
very bare-iron.
this will disconnect the battery and put the device in a very low power
state, and you can only power it back on again by plugging it into
a power source briefly.
tts is working fairly well and much more stably, menus and ui
elements are wired up for tts.
just waiting for the latest braille keyboard pcb to come in and
then we'll be able to fire off some prototypes...
This commit adds the current's app name to the security bar at the top
of the screen, just beneath the status bar.
I had to add a new generated function to map app index back to its name,
along with an enum to signal whether or not the id is valid.
Signed-off-by: Gianguido Sorà <me@gsora.xyz>
Keyboard setting is "the one and only" exception to user settings
that are saved without encryption. This is because you need your
keyboard layout to be set in order for you to type your password.
Thus, this needed a bit of a special-case to handle its storage record.
We decided to lop off 1 page from the loader and have it store
the keyboard layout code.
Let's hope we can have the discipline to really just store that
one word of information and not later be like "gee wally, you have
a whoooole 4092 unused bytes of space we can cram unencrypted
user settings in, sure would be a waste to not put those use those".
Good enough so that if you type `net server` and you hit the IP
address of the device, it'll respond with something like
Hello from Precursor!
I have been up for 86087 ms.
There's still all kinds of bugs, I'm sure. But ... I'm also not
sure /why/ you would want a web server on Precursor. This is more
just to make sure that the TCP stack isn't totally broken.
The "web server" as it may be is quite broken and doesn't parse
any headers and probably sends a bogus amount of data because
I can't figure out if the content length includes some new lines
or not. But really, this just isn't in scope. Works with Chrome,
Firefox shows the status page and then says "connection reset" and hides
all the information. Whatever, browser compatibility is well beyond
my pay grade!
