use millisat amounts for local/remote capacity and can send/receive,
refactor channel capacity graphic to ChannelBar and use that as well
in ChannelDetails
trying to paste a bare nodeid errored silently, logging:
174.76 | D | gui.qml.qechannelopener | AttributeError("'NoneType' object has no attribute '__contains__'")
QEInvoice/QEInvoiceParser now properly split for mapping to Invoice type (QEInvoice)
and parsing/resolving of payment identifiers (QEInvoiceParser).
additionally, old, unused QEUserEnteredPayment was removed.
invoices are now never saved with user-entered amount if the original invoice
did not specify an amount (e.g. address-only, no-amount bip21 uri, or no-amount
lightning invoice). Furthermore, QEInvoice now adds an isSaved property so the
UI doesn't need to infer that from the existence of the invoice key.
Payments of lightning invoices are now triggered through QEInvoice.pay_lightning_invoice(),
using the internally kept Invoice instance. This replaces the old call path of
QEWallet.pay_lightning_invoice(invoice_key) which required the invoice to be saved
in the backend wallet before payment.
The LNURLpay flow arriving on InvoiceDialog implicitly triggered payment, this is
now indicated by InvoiceDialog.payImmediately property instead of inferrred from the
QEInvoiceParser isLnurlPay property.
This is better than nothing, but not ideal. This window should
have a general purpose 'userinfo' field, like InvoiceDialog,
that would also display 'Broadcasting...' while the tx is being
broadcast.
Note that in order to bump the fee again, the user will have to
leave this window and open it again.
Balance details are shown if the user presses and holds the
balance area; the idea is that this should be less chaotic
than if the popup is triggerred by a simple click. However,
we might as well try with a simple click, because we already
do it with transaction details; I am not sure what is the best
option, we should try both.
This also makes 'new channel' and 'swap' buttons available from
theBalance details, so that users do not need to visit the
channels list.
I think this is more intuitive as a "greater than" relation sign
than to use a signal that the label is for the leftmost point in the coloured bar.
As in, "feerates not displayed towards that direction are even higher than this value".
