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.
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.
The basic usecases of instapay is that the payment request is filled in
one go (from QR for instance) and thus we try to send.
If that fails (not enough funds or whatever), we disable instapay in
order to avoid 'magic happens' user experiences.
The headers and such items now get localized on the history pages.
We use static strings for the formats to avoid every call converting a c
string to a utf16 qstring, which takes an allocate and a conversion.
A tiny little amount of data kept in global memory to avoid a large
number of mallocs is a net gain, I'm pretty sure.
The design of HD wallets always has a gap, a number of addresses past
the last used one we optimistically also look at.
My code assumed that there would be only one gap, at the end while the
number of skipped addresses were near zero.
Some other wallet, however, had multiple large gaps which messed up the
algorithm.
Now we restart counting gap-addresses every time an address is used in
the sequence.
Fixes#12
This should fix the problem of a certain established wallet not
importing properly.
That wallet has shown to jump 15 or 20 addresses over the gap, which
made me wonder if that actually is a privacy issue and the conclusion is
that, no, if there is no matching transaction on chain, there is no
privacy leakage from just sending the bloom filter and thus the gap has
been increased for main.
Lets face it, listing loads of addresses is not readable. People can't
really get meaning out of that, its just 'data' after one or two.
Showing the hd-path-id (main or change) and an integer is going to be
much more useful for many UX situations, so we provide that information
for the UI to display that instead.
Naturally, the actual address is still available for copy/pasting etc.
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.
tomFlowee