- on the python side, for pyqtProperty's with a setter, the pyqtProperty should be declared as QVariant type
- on the qml side, properties should be declared 'var', not the custom type.
Shows Wallets.qml as root if no wallet is loaded and removes the logic
for no loaded wallet from the WalletMainView as WalletMainView won't be
shown anymore without a Daemon.currentWallet.
separates the resolving step from the QEInvoiceParser so the 'recipient'
can be resolved first and then either an QEInvoiceParser can be used if
it is a sending request that has been resolved (invoice, address,
lnurlp, ...), or RequestDetails can be used if the resolved 'recipient'
turns out to be a voucher/LNURLW string.
# Conflicts:
# electrum/gui/qml/qeinvoice.py
adds handling of lnurl-withdraw payment identifiers which allow users to
withdraw bitcoin from a service by scanning a qr code or pasting the
lnurl-w code as "sending" address.
qml: add signals for QEQRScanner and fallbacks, add QEBytes container type
so we can pass along byte arrays between QML and python, port qr scan
occurrences to new signals.
when setting a transaction label in the qml
`LightningPaymentDetails` or `TxDetails` dialogs which get opened
directly by the `ReceiveDialog` (`onRequestPaid`) the label is not applied on the main
transaction list as no callback for `detailsChanged` is registered which
gets called when the label changes. As a result the label is only
visible after the main list gets reloaded (e.g. restart).
This commit adds callbacks for `detailsChanged` to fix this.
lightning: implicit save of lightning invoice with override amount deferred until actual payment is accepted.
on-chain: for now, invoice is implicitly saved when override amount is passed to ConfirmTxDialog. (this is sooner
than current desktop client, which saves - and only saves - when Pay is clicked from ConfirmTxDialog)
avoid overloading invoiceParser with new payment identifiers while potentially long-running
resolve/finalize steps are ongoing, show errors inresolve/finalize steps to user.
given a bip21 uri that has both onchain addr and bolt11,
if we have LN enabled but no LN channels, auto-fallback to paying onchain
we will have to clean up and unify this logic between GUIs. becoming spaghetti :/
rumour has it, Thomas has a branch? :P
Sander van Grieken