[GUI] Update QR Code on address selection

[WetOne]

Problem

Selection of an address on the Address Book page does not update the QR codes on the receive page or the left hand side.

Root Cause

Selection of an address on the Address Book page is isolated to the address book.

Solution

Notify the other displays to allow for updates based on the selection of an address. The update includes displaying address, QR code, name (if any).

Issues Addressed

250: #250
136: #136

[CaveSpectre11]

Investigating oddity with it pulling contact addresses.

[CaveSpectre11]

This needs to be the updatedIndex.

[WetOne]

Updated the line. both index.row() and index (the last argument) have been updated to updatedIndex.

[codeofalltrades]

In the console enter getnewminingaddress
Go to the contacts tab
Select the mining address.
Displayed address wrong
The copy button copies the incorrect address.

[CaveSpectre11]

In the console enter getnewminingaddress
Go to the contacts tab
Select the mining address.
Displayed address wrong

I think it's decoding it into a destination address:

        LogPrintf("%s: index %d %d, updatedindex %d %d, addressStr = %s\n", __func__,
                  index.row(), index.column(), updatedIndex.row(), updatedIndex.column(), addressStr.toStdString().c_str());
        CTxDestination selectedAddress = DecodeDestination(addressStr.toStdString());

2021-01-03T03:32:52Z handleAddressClicked: index 6 0, updatedindex 8 0, addressStr = VKR4AXDC3mRq2zNfAhrMYgh1i74FbP6XwW

Probably have to dig into the bowels of the CTxDestination to determine if it should leave it as a raw address or decode it.

[codeofalltrades]

copy via the tooltip copies the address that is displayed.

muQ3R2f8o2cf9S4gRGTxPJvXgU7zcP2a8z

[WetOne]

@codeofalltrades, I think @CaveSpectre11 is correct - it is trying to decode the passed address into a destination address. The code was originally intended to only show a stealth receiving address (specifically, a stealth receiving address named "stealth", if you didn't have one, one is created for you). The implementation was not intended to have anything other than a receiving address displayed. What is your preference: to only have stealth receiving addresses displayed, or be able to have all non-contact addresses displayed (any address the My Addresses tab)?

[codeofalltrades]

or be able to have all non-contact addresses displayed (any address the My Addresses tab)

From a consistency perspective it should be all addresses. However with the move away from other coin types/addresses doing the work to support those types doesn't make sense resource wise. @CaveSpectre11 thoughts?

[CaveSpectre11]

or be able to have all non-contact addresses displayed (any address the My Addresses tab)

From a consistency perspective it should be all addresses. However with the move away from other coin types/addresses doing the work to support those types doesn't make sense resource wise. @CaveSpectre11 thoughts?

I'm not sure how much work it would be to recognize the coin type. It probably is possible, I'm sure there's a routine. If there's a routine to check it and it's a couple lines of code (if !miningAddr, Decode destination), then it might be worthwhile since we don't have mining to stealth yet.

But if it's not simple, probably let it go. But test it and see if you can send to that decoded address. That would change the priority. If they can't send to the decoded address, then that's a definite problem and we'll need to detect it.

If we can send to the decoded address; I'll let you make the severity call.

[codeofalltrades]

If we can send to the decoded address

looks like a no on the decoded address.

[CaveSpectre11]

If we can send to the decoded address

looks like a no on the decoded address.

I'm wondering if it's a problem in decode destination; where the leading character isn't recognized; or otherwise decoding incorrectly for a mining address; which could also be related to the stuck mining spend problem.

[WetOne]

@CaveSpectre11 , @codeofalltrades : This is almost definitely the encode/decode. Do we know what needs to be changed other than the mining address? The update for the mining address looks simple enough. I would like to make the change once.

[WetOne]

With a little more digging I found that the problem appears in the lines where EncodeDestination(arg1, arg2) is called. In my implementation arg2 is always set to true. This needs to be changed to be "if !(receive_miner == purpose)" in both balance.cpp and receive address widget.

The change will definitely fix the issue with receiving miner addresses. I don't see any indication in the code that more needs to be done for other addresses. Let me know if you want me to just push the one change or if another update needs to be made.

[codeofalltrades]

My vote is push the one change.

[CaveSpectre11]

My vote is push the one change.

Agreed. Let's get it in here and make sure everything looks the way that's needed.

[WetOne]

@CaveSpectre11, @codeofalltrades
Updated. Testing with mining addresses worked.

[CaveSpectre11]

ACK 7cf0778

[codeofalltrades]

ACK 7cf0778