Fix #392.
Adding a new item to the m_wallet_selector must follow the establishment of a connection between the WalletView::encryptionStatusChanged signal and the BitcoinGUI::updateWalletStatus slot.
This was a regression introduced in https://github.com/bitcoin/bitcoin/commit/20e2e24e90d782219e853ef0676ac66dc6a9de6a (#29).
An encrypted wallet being auto-loaded at the GUI startup:
Adding a new item to the m_wallet_selector must follow the establishment
of signal-slot connections.
ACK d54d94959869b0c363939163b99ba0475751dcb6
Tested that this fixes the issue.
For those wondering why this fixes the issue, m_wallet_selector->addItem ends up calling a lot of setup functions and emits several signals. One of those signals is encryptionStatusChanged. However previously this signal was not connected to its slot so when that signal was emitted, it did not have the intended effect of greying out the Encrypt Wallet option. By moving addItem to after all of the signals have been connected, the signal will be correctly handled.
ACK d54d94959869b0c363939163b99ba0475751dcb6
Tested on macOS 12 and Ubuntu 20.4.02
The related code is a bit entangled, but I have ensured that this is correct in its implementation and is a good way to fix the issue. Below are screenshots comparing master and this PR:
| Master. | PR. |
|---|---|
This was tested by starting with an already encrypted wallet. On the master branch, we can notice the issue described in #392. On the PR branch, we can see that this is fixed.