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".
I think we can re-enable the requests list, because requests
are now created explicitly by pressing the create request button.
Since this is an advanced feature, it should not be in the way of
people who do not want to see it. Here is a solution that might
work.
"defaultServerChanged" was not the right event to listen to. It is only sent
*after* the interface is ready.
"network_updated" is a bit overkill as it is triggered every time any of the
interfaces goes down or a new one is created, still, better to trigger a
few more times than to be stale.
In particular, if there is no internet connection, the server string is now
updated as expected, instead of showing stale values and ignoring trying
to change servers.
Also, a further state that did not exist before: just like it worked in
the kivy GUI, if the main server was changed but it is not yet connected,
instead of showing the old server still, we now show f"{new_server} (connecting...)".
The qt, qml, and kivy GUIs have a first-start network-setup screen
that allows the user customising the network settings before creating a wallet.
Previously the daemon used to create the network and start it, before this screen,
before the GUI even starts. If the user changed network settings, those would
be set on the already running network, potentially including restarting the network.
Now it becomes the responsibility of the GUI to start the network, allowing this
first-start customisation to take place before starting the network at all.
The qt and the qml GUIs are adapted to make use of this. Kivy, and the other
prototype GUIs are not adapted and just start the network right away, as before.
