adds some delay before detecting the scrollbar in the terms of use
dialog. This prevents it from falsely detecting a scrollbar and
disabling the "I Agree" button even if there is no scrollbar. I noticed this
issue on windows, the order in which the window is created seems to be
slightliy different from linux/wayland there.
This is purely informational and optional, with the main immediate use to provide the
invoice description/message/label to the transaction dialog, so it can be stored
when saving the tx in history, or passed along with PSBTs sent to cosigners.
Before, the tx description was not saved in history when an invoice was not saved before
signing and saving the tx for sending later.
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)
disable the checkbox by default, so that if a user selects Enable Proxy
in the advanced network settings, and then just clicks next with the proxy
checkbox set, doesn't end up with a invalid proxy configuration which
doesn't connect to the server and has to be fixed manually.
the edit label button did crash the application because get_string
returned bytes instead of a string. The delete button was not
implemented but shown in the tui.
if payment amount is not set and the user tried to pay, the application
would crash. This shows a message instead. Also uses show_message
instead of show_error, as show_error doesn't exist.
There was no ability to read qr codes contained in image files. This
could lead to confusion in some contexts, as `on_file_input()` of
ScanQRTextEdit will read the whole content of the file (instead of
looking for qr codes). The revealer plugin for example generates png
files containing qr codes and uses the `ScanQRTextEdit` to get user
input, for the user it would seem logical to click on 'Read from file'
to load the generated file, however this will result in the wrong data
being loaded. Having the option to explicitly load a QR from file makes
this clear. Also it seems useful, especially considering reading QR from
screenshots doesn't work on wayland.
- if password is needed, await future and request it from GUI
- run asyncio task for each TxBatch, so that batches can
request the password concurrently