When raising generic Exception, window.on_error can't tell whether
there was a programming error or we just want to communicate with the user.
E | gui.qt.main_window.[default_wallet] | on_error
Traceback (most recent call last):
File "/home/user/wspace/electrum/electrum/gui/qt/util.py", line 832, in run
result = task.task()
File "/home/user/wspace/electrum/electrum/gui/qt/main_window.py", line 2900, in <lambda>
task = lambda: self.network.run_from_another_thread(
File "/home/user/wspace/electrum/electrum/network.py", line 358, in run_from_another_thread
return fut.result(timeout)
File "/usr/lib/python3.8/concurrent/futures/_base.py", line 439, in result
return self.__get_result()
File "/usr/lib/python3.8/concurrent/futures/_base.py", line 388, in __get_result
raise self._exception
File "/home/user/wspace/electrum/electrum/wallet.py", line 162, in sweep_preparations
raise Exception(_('No inputs found.'))
Exception: No inputs found.
I think on_release has better UX.
More importantly, on desktop linux with kivy 2.0.0rc2, on_press does not work for me.
(but on Android, with kivy 1.11.1, it does)
- our new key now supports both
- note that we don't bother to "dual sign" for both sha1 and sha2, as
Win7 upwards sha2 is supported (and we already don't support XP, Vista, etc anymore)
Create a pyinstaller "onedir" executable instead of a "onefile" executable.
Note that the name change from "Electrum" to "run_electrum" affects the
name of the internal binary (usually not exposed to users). This is
needed to avoid a collision with the "electrum" folder inside the .app
(just like in the source tree).
based on 03c3eca856
maybe fixes#6225
Previously this function would not switch to a different chain if the
current chain contained the preferred block. This was not the intended
behaviour: if there is a *stronger* chain that *also* contains the
preferred block, we should jump to that.
Note that with this commit there will now always be a preferred block
(defaults to genesis). Previously, it might seem that often there was none,
but actually in practice if the user used the GUI context menu to switch
servers even once, there was one (usually genesis).
Hence, with the old code, if an attacker mined a single header which
then got reorged, auto_connect clients which were connected to the
attacker's server would never switch servers (jump chains) even
without the user explicitly configuring preference for the stale branch.
ThomasV
SomberNight
richard
relativistic electron