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.
This moves the component out to its own file while fixing some UX
issues.
* It is now always visible for (UI) discovery purposes.
* When we paste when there is no matching text we show negative
feedback.
One surprise was that the main usecase of pasting is one where the user
activates another app to go and copy data in order to come back to paste
it.
And the Qt clipboard didn't manage to get any notification of clipboard
changes. Even copying data on becoming active had no effect.
So now I just show the paste optimistically when the user comes back
from another screen, assuming the main reason for that was to copy.
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.
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.
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 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.
tomFlowee