Not all usages of the old 'QR' image were about scanning, so the
added photo frame ended up causing a UX regression for those
that were used to indicate showing a QR.
Instead we now have 2 icons (at 4kb ascii text each, thats literally
not a big deal) to acoid this confusion.
This removes the dependency on the QrEncode lib and uses
the fact that our scanning lib also is capable of making QRs.
We now allow the QR to get its color inverted for dark mode
users, making it less bright to show a QR.
This introduces a new QR-creation mode which allows spaces and
other chars to be in there directly without being URL-encoded.
This improves the QR showing of the user's seed-phrase (in the
backup screen).
This adds the ability to scan a seed phrase with your camera by
adding a button to the wallet import page.
This also adds support for the QR format that the bitcoin com
wallet uses in its QR for seed phrases.
This includes a self-drawn SVG of a ribbon, configurable text on top and
just a simple checkbox to recognize that at this time there is only one
category-type. KISS.
clipboards based addresses are a lot less secure, physically, than
scanning a QR.
So the user really should validate the payment and thus we turn off
instaPay in those cases.
When looking at the real usage of flowee pay, we aim for this
to be used 90% (or more) of the time as a better wallet. Wallet
in the physical sense.
This implies that the vast majority of usage is going to be about
paying or receiving.
A small number of times you'll use it to look up the history of
payments.
As such, its Ok to downgrade the account history and make the main
usage more prominent and easy to find.
The scanner doesn't validate the QR, but the Payment object does. So,
verify the result after setting the url on the Payment object and raise
a dialog when the address did not work.
As long as the user has not added a second wallet there is no
need to show the name 'initial wallet' and thus we show the
'add wallet' button at the bottom.
A Payment object now has a user-typed address,
a formattedAddress which is a properly formatted cash-address
and last a 'niceAddress' which is the same cash-address but without the
chain prefix.
This cleans up the usage and removes some code from the GUI that did the
string manipulation there.
A payment request, for instance a QR code, which includes an amount to
be paid is expected to not change the to-be-paid amount, uses being
dropped
in the price editing UI is therefore a bit weird. Almost an
anti-pattern.
This honors that concept and when the price is included in the scanned
QR, we change the UI layout to removed the editing widgets and show
static display widgets instead.
This also adds a header menu item to edit the amount to be paid and
get back to the old UI.
Additionally, a new UI is added to show the address we are about to pay
to, likewise reachable from the header menu.
This solves the UX issue that the touch-screen keyboard would
overlap on our main content and that we could actally not input
a price properly on mobile at all.
This redoes most of those pages to look much nicer and in-place.
This also disables the 'create' button when the derivation path is not
correctly entered.
This now brings the functionality to archive a wallet to the mobile
interface.
Archived wallets don't show up in your main view, do not synchronize
with the network and any balance they may 'contain' is ignored.
This brings the new 'privacy mode' to use the standard widgets
and make the UX more smooth.
The swiping between pages / wallets is more visually satisfying.
We update the sync label to have a live counter of how long ago
the last block came in. (both front-ends)
A wallet can permanently be labeled a 'private wallet' which is a simple
boolean.
Then when you may need to hand over your phone to a clerk, all you do is
quickly enable the 'private mode' which is sufficiently deep in the menu
to make it hidden.
The effect is that all wallets marked private will be hidden for the
duration of that feature being on.
tomFlowee