This makes available a clipboard helper component in QML.
Based on filters we then can make the 'paste' button visible and
only allow pasting stuff that is remotely useful.
This then also adds a 'paste' button to the transaction-building
module, the 'destination' screen.
For desktop we now properly support starting a payment when
the user clicks on a bitcoincash link in a browser.
For Android the activation logic _should_ work, except that the
Android specific way has yet to be tied to our app.
Squash of 12 commits, this makes the UX actually useful and
we detect errors and show errors and warnings to the user.
This also adds an 'editable' bool to OutputDetail in order to
disable editing of a payment request address.
Additionally, this introduces the ability for a Payment to carry
a raw script instead of an address. So op-return or more complex
payment requests will be sent just fine.
Fun fact is that our broadcast is INV/SendData, which is two
roundtrips and thus slow, which is needed to be sure we get proper
rejection messages.
The sending of the transaction via BIP70 causes the network to
already know about the tx because the server we send it to has
likely much better Internet than we do.
So confirmation from the payment provider is used to show success
instead of the normal way.
This adds the basic support of bip70 style payments.
Some todos are left which are mostly about interaction with
other parts of the app and require bigger changes to make
it work smoothly.
The PaymentProtcol class now handles the pasting of a payment uri,
like bip21.
Additionally this adds the feature where we pass in the payment uri on
the commandline which then results in an auto-opened payment screen.
The backend will tell us that there is good reason to believe the remote
needs to get a new bloom filter, which is causing a lot of extra traffic
if there actually is no change in the utxo of the wallet.
This introduces a bool to mark changes that would affect the bloom
filter to be send, and only upload a new one when that bool is true.
Parsing the amount
0.00522325
caused the double to have a 49999 at the end instead of that 5.
This now will be rounded back up the the proper sats value.
We already allowed individual wallets to get PIN-to-Open/PIN-to-Pay
but that is too advanced for most users. Not to mention that encrypted
private keys means a slower payment process and certain types of
features become impossible. Like auto-invoicing (incasso).
The gap, for mobile, is a simple not-encrypting password on startup
of the app which is likely what 80% of the privacy / security minded
people on mibile will be more than happy with.
This adds this mode and additionally streamlines the encrypted modes
of wallets.
The model had much more functionality we'd ever use in the UI, it turns
out it was over designed.
Remove the unneeded complexity and just have one simple list.
this also changes the API propertes that handle encryption details a
little. Making them faster and the meaning follows the logical
conclusion of the naming better.
Specifically:
when needsPinToOpen would return true, now needsPinToPay will also
always return true.
This now uses the new Qt APIs for requesting camera permissions
on supported platforms (Adnroid and iOS).
There are still several ifdefs and the older code is still there,
lets leave that for some releases, because why not.
This is a long overdue cleanup around the ideas of entering
numbers in Flowee Pay.
The core dataclass BitcoinValue now keeps track where the number
came from, either user input or some calculation. This allows
us to have the Fiat and the Coin price stay in sync without weird
problems.
The one we type uses a string, the price field that we are not typing in
is then a slave and we follow the auto-generated number as the
source.
This solves a host of known issues:
* Editing of value objects is much more consistnnt and predictable now.
* Switching to a different fiat type now properly re-calculates the
values that are slaved. So if the primary is a BCH value then the fiat
value gets the new exhange rate instantly applied.
* Switching to a different fiat type properly applies having a separator
So if you go from euro to Japanese yen, we now remove the separator
and the numbers behind it.
* Changing the app setting from BCH to mBCH now properly updates all
amounts. Notice that the user-typed string wins, if you typed 2 and
then change to mBCH we assume you wanted 2, not 2000.
* Paste now works more logcally.
* Cursor is no longer sometimes invisible, requiring backspace to make
it show up.
And last we now protect against too large numbers. It is seen as an
error to type a number above 21 million BCH.
Fixes#19
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.
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 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.
tomFlowee