Always use "." as decimal point, and " " as thousands separator.
Previously,
- for decimal point, we were using
- "." in some places (e.g. AmountEdit, most fiat amounts), and
- `locale.localeconv()['decimal_point']` in others.
- for thousands separator, we were using
- "," in some places (most fiat amounts), and
- " " in others (format_satoshis)
I think it is better to be consistent even if whatever we pick differs from the locale.
Using whitespace for thousands separator (vs comma) is probably less confusing for people
whose locale would user "." for ts and "," for dp (as in e.g. German).
The alternative option would be to always use the locale. Even if we decide to do that later,
this refactoring should be useful.
closes https://github.com/spesmilo/electrum/issues/2629
* add invoice status to invoice_status callback
* debug statement fails tests
* removed commented lines, added progress/attempt counter comment in lnworker.pay_to_node,
and update the invoice_status event handler in qeinvoicelistmodel.py
window.run_coroutine_from_thread starts a coroutine on the asyncio loop,
which, when finishing, pops from the dict.
The for loop in clean_up is running on the Qt thread.
fixes https://github.com/spesmilo/electrum/issues/7983
fixes https://github.com/spesmilo/electrum/issues/7919
In the past, when creating payment requests, we keyed them by on-chain address,
and set/saved the msg of the request as label for the address.
Many places in the code were calling wallet.get_label(addr) with the expectation that
relevant payment requests are found and their message/description (if any) is considered.
wallet.get_label(key) is now made private, and instead the explicit non-polymorphic
wallet.get_label_for_{address,rhash,txid} alternatives should be used.
fixes https://github.com/spesmilo/electrum/issues/7780
fixes https://github.com/spesmilo/electrum/issues/7815
Re FIXME in main_window.py, in particular, adb might call `add_transaction` on the same tx multiple times.
In `wallet.on_event_adb_added_tx`, maybe we should propagate `notify_GUI` to `wallet._update_request_statuses_touched_by_tx`.
The issue being fixed here (above TARS reports) can be triggered in multiple ways, e.g.:
- have an already paid receive request, and receive a payment to the same address again
- have an already paid receive request, and *spend from* that address (in which case the history of the address will change, and address_synchronizer will call add_transaction again on the old tx that satisfied the old receive request)
- 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
- separate AddressSynchronizer from Wallet and LNWatcher
- the AddressSynchronizer class is referred to as 'adb' (address database)
- Use callbacks to replace overloaded methods
- 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.
