This adds a setting in the mobile client where the user to select to
prefer to start inputting the BCH value on payments (that require manual
input of price).
The default is to start with the user selected fiat value.
For Page inhering screens (BroadcastFeedback/UnlockApplication)
This changes the Page.hideHeader to now act like a full screen,
removing all insets from the Page object when enabled.
The insets are then re-added on the child pages, but
without affecting the background fields, so they cover the insets.
UnlockApplication is a simply full screen widget, we added the
insets to it too.
This fixes a bunch of little issues and possible issues, including the
ability to swipe horizontal the main transaction view before we have a
second tab to scroll to.
This also re-enables the adding of the action that turns a payment into
a repeat payment. Currently our only way to create them.
A bit hidden, but we expect that in future other methods will become
available that make more sense.
To allow a bugfix release to be sent, lets remove the one action
that can open the entire path to repeating payments for now.
Allowing more time to be used for actually making repeat payments
first public release more smooth.
The non-themed import basically is just a proxy using some
auto-detection to find out which theme to use.
As the app only uses the basic theme, this is what we'll import.
This changes the notes property to be only set by the user of the
BroadcastFeedback.qml, and not from inside anymore which could break the
property binding causing strange things to happen.
In the send-sweep module as well as in the PayWithQR this removes
the UserIntent handling and instead moves that to the main.qml
exclusively.
Additionally in the send-sweep module the camera work is split
into its own page, like in the other parts of the app. This helps
us avoiding hacks when we want the main functionality without the
camera.
This is the last of the series of reworks, we should have all
former functionality working again.
The initial design has done well for over 2 years, but problems
are starting to show.
This does a bit of cleanup in the UX and many cleanups in the
underlying architecture that were the result of those UX choices.
We remove the clipboard (paste) concept from the camera pipeline
completely and simply make it a new top-level button "paste" on the
send page. This helps discovery AND helps architecture!
The both workflows now also become 2 stage affairs, when the button
is pressed we open a page that does the scanning or pasting and then
introspects the actual data in order to redirect to the right page.
This means that we auto-detect if the scanned item is an address or
a private key or whatever, and handle it appropriately without needing
any user interaction.
The idea of using Flowee Pay to open a payment screen, or a sweep
screen, was so far married to the executable lifetime due to it being
passed as a command line argument.
This does not reflect reality, on neither desktop nor on mobile as
multi-tasking is possible and we should allow that.
As a result the new object "Intent" has been introduced with the
usecase specific properties. Setting those properties at any time
during the lifetime of the app now pushes the correct page to the
stack on mobile. Desktop is in need of more love in this department.
This specifically allows pasting and scanning of bitcoincash addresses
without the 'bitcoincash' prefix.
Additionally this cleans up the QRScanner API a little and merges two
methods.
Last, at popular request, this makes showing the address on the
confirmation screen default to be on.
This allows people to actually verify the address they pay to.
Except when paying to a BIP70 payment because that is practically
speaking a system that avoids talking about addresses in the first
place. No point in trying to verify the actual address THERE.
In the case where there is no specific input needed, because the amounts
were all specified, we still need to set the focus to the page because
otherwise 'back' / 'esc' don't behave correctly.
The CPP now does more of the (heavy) lifting and the UI layer can
ignore
most of the details with regards to there being digits behind the
separator for fiat at all.
The internal change is that the fiat based values are always processed
in cents, even if the cents are not displayed. This solves incorrect
display and generally removes special cases.
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.
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 QR scan page now also allows showing the destination address
while the number keypad is up, being smarter with the layout of
the various lines in order to fit the important info on screen.
Additionally we require the user to first enable the 'edit amount'
option before we make available the option to 'send all'.
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.
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 detects that the currently selected wallet is fully encryted and if
it is, it shows a password request page on top of the current screen.
The default setup aims to have people type a PIN in numbers to unlock
the wallet, but we also provide a way to make it use a textual password
instead.
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.
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.
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 GUI confused 'userowned' and having a list of wallets.
Basically we can just trust the backend 'accounts' list, making
the GUI eaier to understand.
In Qt5 the palette was introduced in the Control object (part of Qt-
Quick-Controls-2).
In Qt6 this property was moved to the superclass 'Item'.
This means that we no longer need to refer to a control when using a
palette, every single thing in QtQuick is an Item, afterall.
tomFlowee