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.
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.
This makes the payment detail (output) have the same property name as the
payment itself which was supposed to just be a proxy for a single-output
payment.
Consistency is good.
This merges the paymentAmount and effectiveBchAmount methods because they
did 99% the same.
Same with the paymentAmountFiat and effectiveFiatAmount.
This removes the 'effective*' set of properties.
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.
This shows all wallets and wallet details.
Additionally, this moves the AccountTypeLabel out of the desktop page to
be reusable. Not so much because its hard, but because they have
translations and we'd better push shared translations into the common
translation unit as opposed to duplicating it.
The LabelWithClipboard now has as default context-menu-item text "Copy"
instead of "Copy Address".
The 'text' and 'windowText' were both used like they were the same
thing, which they currently are but don't have to be.
Now migrate the various cases where to we use 'text' to 'windowText'.
This choice is made because the Label object uses windowText by default.
In future we might want to make the 'text' one have a slightly different
color. Its still used in Qt components like the popup menu.
When the user changes unit (BCH / mBCH), the widget would not update
until you typed something. Creating a surprise moment.
This fixes that, at the expense of a seemingly innocent warning by QML
about a binding loop.
The usage of the big application singleton for enums is not the best for
linkage.
See, in QML you like to use enums, but you need to register the object
it is defined on with QML. So, you ideally have one object with loads of
enums. Easy to maintain, less to learn for the QML author.
Using the application-wide singleton made kind of sense, but this
creates a dependency requirement for all users of these enums that
doesn't jibe well with maintainable code.
So, introduce a simple enums-only class that can be used from QML and is
cheap to include from any using classes.
tomFlowee