Currently requests are sent from the requestor's thread. The lock is
not properly held where necessary so this is not thread-safe. For example
it can race with the thread stopping and closing the socket the
requestor is trying to use to send with.
Resolve such races by having send_request() simply queue the requests,
which are asynchronously sent from the interface thread itself.
First step in cleaning up the run() function.
Calls stop() rather than setting is_connected to False on
case of timeout, which cleanly closes the socket.
Solves the following warning every time electrm is run:
libpng warning: iCCP: known incorrect sRGB profile
There is lots of information about this on the internet, see e.g.
https://wiki.archlinux.org/index.php/Libpng_errors
We store it in the config object instead of in the blockchain object.
The blockchain object now refers to its config, and calls refresh_height() to update it.
The network objects also refer to the config rather than the blockchain.
This is the first of many small steps to untangle the verifier from stored state and so
permit the history tab to work in offline mode. The refactoring will simultaneously clean
up a lot of accumulated cruft.
The call to update_wallet() is redundant with earlier call to load_wallet().
Set the need_update boolean so the timer will refresh rather than
unconditionally refreshing. This typically results in it merging with
the first network "updated" event resulting in one less refresh.
For me in online mode this results in history being calculated and shown
only twice during startup rather than four times.
Electrum 2.x flashes a small window during startup before the main window appears.
This turns out to be the fee edit box being enabled in create_send_tab().
Setting it to visible when the grid containing it is unparented causes QT to actually
display a window with just the edit box widget for some reason. So defer the
call to set its visibility until the grid is parented.
The goal is to be able to run local instances from arbitrary directories.
It seems that the chances of having a setup-release.py in the same directory
as an installed electrum are extremely remote: not only is the name unusual,
but the file isn't installed anyway.
ThomasV
Neil Booth
ThomasV
Maran
pooler