As the name is so much wider the widget didn't work well, this
makes the name not overlap.
Additionally, added a space beteween the currency name and
the numbers.
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.
This sets up a basic system for creating modules on top of the flowee
pay static lib in a way that is ensured to be isolated (modules can't
accidentally use each other's classes)
The setup is made such that the buildsystem does the hard work on
plugging in a new module, making it so that all you need to do is create
a new dir and a "{something}ModuleInfo.h" file and it will get compiled
in.
The point there is to make it not have any merge conflicts and just make
it dead easy to get started.
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.
tomFlowee