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.
The actual touch area was exactly the checkbox, which is really not that
big an area for a finger to touch.
This assumes that the layout has 10 pixels between components and thus
we eat 5 above and 5 below this component to increase the touch-area to
the max we can.
We ship our own font to not have to depend on the host system's
installed fonts for 'special' characters like arrows and stars.
This is a font forked from the Gnu-free font people, only since that one
is 2MB this is a very much stripped down version with just all the fun
stuff left.
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.
tomFlowee