I am only making this change as it makes it simpler to do manual testing of CPFP-ing *local* txs.
That is, by changing a few easy-to-find lines of code, I can make the GUI allow CPFP-ing a local tx, but
without this change it errors out with "unknown fee for parent transaction".
If one has an incoming local tx saved in the wallet, adb.get_tx_fee(txid) returns None
(if the tx gets into the mempool, it will use the server-reported value instead).
In contrast, wallet.get_tx_info(tx).fee calls both wallet.get_wallet_delta(tx) and adb.get_tx_fee(txid),
making it more expensive but more complete.
On Android, we disallow screenshots on screens where the seed is visible.
(The seed is extremely sensitive data that should not be stored digitally without
significant precautions but it's also cumbersome to write down or memorise, so
some people instinctively just try to take a screenshot of it when creating a wallet.)
We do this by using the built-in OS mechanism of setting FLAG_SECURE on the window.
However, on some devices with custom ROMs (one report from LineageOS, one from /e/OS),
unsetting FLAG_SECURE crashes the application for some reason.
As a workaround, this commit adds a config setting into the Preferences,
to disable this mechanism and just always allow screenshots.
(note that you can get into the qml Preferences before creating/opening any wallet)
ref https://github.com/spesmilo/electrum/issues/8522
...\electrum\electrum\logging.py:137: DeprecationWarning: datetime.datetime.utcnow() is deprecated and scheduled for removal in a future version. Use timezone-aware objects to represent datetimes in UTC: datetime.datetime.now(datetime.UTC).
...\electrum\electrum\x509.py:310: DeprecationWarning: datetime.datetime.utcfromtimestamp() is deprecated and scheduled for removal in a future version. Use timezone-aware objects to represent datetimes in UTC: datetime.datetime.fromtimestamp(timestamp, datetime.UTC).
Correction to comment in prev commit (and removing it here):
spec.loader.exec_module does not spawn new threads, it simply
executes the module in the current thread.
I got confused but turns out "load_plugin" itself is sometimes
not called from the main thread. Specifically (e.g.), since the recent
wizard rewrite, in the qt gui, the wizard loads the hww plugins
from a new thread.
This now better explains the macos hww crashes: they had started
appearing because we upgraded hidapi (which made it more sensitive
to having to import from main thread) AND scanning(->importing) from
the wizard no longer happened on the main thread after the rewrite.
Plugins should be thread-safe in terms of where they are imported from.
Let's log the importer thread's name (added here), to help recognise
related threading issues.
- risk_of_burning_coins_as_fees is turned into a private (helper) method, only called by check_sighash.
UIs should only care about check_sighash.
- check_sighash returns instance of new class "TxSighashDanger" instead of tuple
- made warning levels more fine-grained (FEE_WARNING_SKIPCONFIRM vs FEE_WARNING_NEEDCONFIRM)
- this became more complicated than I had hoped for but I think it is worth it to ~merge
check_sighash and risk_of_burning_coins_as_fees into one.
related https://github.com/spesmilo/electrum/pull/8699
I think it's nicer for the network status to be rightmost, which was the case for a long time.
(Though plugins are still added after (via multiple different mechanisms, see 2fa, hww, revealer).
We could perhaps add a VLine separator, or add them to the left instead.)
follow-up 90d1d587e8
follow-up https://github.com/spesmilo/electrum/pull/8651
We cannot do direct comparison of path-like strings without normalisation.
E.g.
```
relative_path() cp1. path='c:\\users\\user\\appdata\\roaming\\electrum\\wallets\\9dk', wallets=C:\Users\User\AppData\Roaming\Electrum\wallets
relative_path() cp2. commonpath='c:\\users\\user\\appdata\\roaming\\electrum\\wallets'
relative_path() cp3. new_path='9dk'
```
