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.
does not work with current beta:
```
d142c5534f4da4a7f0a1f52676716908f674ff9e06b87f7b153384b161296eaf /home/user/wspace/electrum/contrib/android/../../dist/Electrum-4.5.0.0-armeabi-v7a-release-unsigned.apk
+ mv dist/Electrum-4.5.0b0.0-armeabi-v7a-release-unsigned.apk dist/Electrum-4.5.0b0.0-armeabi-v7a-release.apk
mv: cannot stat 'dist/Electrum-4.5.0b0.0-armeabi-v7a-release-unsigned.apk': No such file or directory
```
- 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'
```
- For the notarisation, we were using "altool" (part of xcode), but Apple now fully deprecated that.
- need to migrate from altool to notarytool
https://developer.apple.com/news/?id=y5mjxqmn
- currently using macOS 10.14.6
and xcode 11.3.1
- notarytool requires xcode 13+
- xcode 13 requires macOS 11.3
https://en.wikipedia.org/wiki/Xcode#Version_comparison_table
==> created new build VM with macOS 11.7.10 and xcode 13.2
Sander van Grieken
SomberNight
sha-265
ThomasV