- in lnurl.py, make request methods async
- in Qt GUI, lnurl network requests no longer block the GUI thread
- but they still do in the kivy GUI
- "lightning address" (LUD-16) support is removed for now as the
email addresses are indistinguishable from openalias email addresses
(both protocols should have added and enforced a prefix, or similar,
to remove this kind of ambiguity -- now we would need to make a
network request just to identify what kind of ID we were given)
- add param to _check_text to toggle if network requests are allowed ("full check")
- every 0.5 sec, if the textedit has no focus, do full check
- on textChanged()
- detect if user copy-pasted by comparing current text against clipboard contents,
if so, do full check
- otherwise, do partial check
- on clicking ButtonsWidget btns (scan qr, paste, read file), do full check
The `WE_ARE_TOXIC` state is added as a sanity check to ensure that if
the remote has proven that we have lost state we do not accidentally
do a local force-close. E.g. if we receive an "error" message for the
channel, we might normally do an automatic force-close. Manually
force-closing in such a state is not offered anymore by the GUI.
The `REQUESTED_FCLOSE` state is added as it is quite likely that
we receive an error message from the remote after requesting a fclose,
e.g. during a later chan-reestablish. In such a scenario, we should
not do an auto-local-fclose, however the manual option of a local-fclose
should still be offered.
- separate AddressSynchronizer from Wallet and LNWatcher
- the AddressSynchronizer class is referred to as 'adb' (address database)
- Use callbacks to replace overloaded methods
this ports https://github.com/Electron-Cash/Electron-Cash/pull/1371
including commits:
---
bab816e2c3
Buttons Editor: Make background non-transparent and change to push button
There were some issues with transparent backgrounds with QToolButton on
Linux and as there is no real reason for them to be transparent we just
make them opaque.
---
2cb698affc
Pay to editor: Fix size computations to use the proper values
Previously this did not take into account the spacing between lines nor
the margins of the control and the document. There is also a sensible
minimum height of one line now and it expands to up to 10 lines before
we show the scroll bar. When the scroll bar is active, we move the buttons
so they do not obscure the scroll bar.
---
1b7a70f4f5
Pay to editor: Increase height by one if cursor is under buttons
---
abd42d9f66
Buttons Editor: Always center if the document is just one line high
---
33bd0b82e0
Pay to editor: Make button movement on scrollbar change reliable
---
94f8476c2e
Pay to editor: Use document lineCount instead of height
---
5bedfce392
Buttons Editor: Improve vertical centering of the buttons, needs to take into account the frame width
---
0cd0b490c4
Buttons Editor: Add transparent border which is somehow needed for correct macOS layout
```
E | gui.qt.exception_window.Exception_Hook | exception caught by crash reporter
Traceback (most recent call last):
File "...\electrum\electrum\gui\qt\channels_list.py", line 377, in new_channel_with_warning
self.new_channel_dialog()
File "...\electrum\electrum\gui\qt\channels_list.py", line 399, in new_channel_dialog
return d.run()
File "...\electrum\electrum\gui\qt\new_channel_dialog.py", line 133, in run
if self.min_amount_sat and funding_sat < self.min_amount_sat:
TypeError: '<' not supported between instances of 'str' and 'int'
```
- use SetMinimumSize instead of sizeHint
(partially reverts 28f794b63b)
- to deal with small window sizes, set MinimumHeight of the
parent TabWidget (with a few extra pixels for margins)
- add an extra layout around address_help_text, so that it has
margins (margins were removed in 28f794b63b)
Previously the receive_tabs widget was allowed to be much smaller
than its inner main widget (e.g. truncating visible QR code).
A bit hackish to overwrite/monkeypatch sizeHint,
but I've tried a few approaches and this seems to work best.
Disable rebalance/swap suggestions attached to requests/invoices if there is an ongoing task.
Note: This assumes that all tasks are lightning payments, which is true for the moment.
These methods return a list of channels that can be rebalanced,
in order to receive or send a given amount.
Also add 'channels' parameter to submarine swaps.
Previously, swaps were not considering which channel to use.
When we do not have liquidity to pay an invoice:
- add 'rebalance' option in order to pay an invoice
- use the suggested channel in the 'swap' option
When we do not have the liquidity to receive an invoice:
- add 'Rebalance' and 'Swap' buttons to the receive tab