Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
need to unify QR codes
See original GitHub issueThe receive tab and address dialog make quite different QR codes for the same address.
- Receive tab QR encodes:
BITCOINCASH:QR8ZT8NCV94RSNC0LFKUJ3QVDZU2JTY2ASQ44CJHKU - Address tab QR encodes:
qr8zt8ncv94rsnc0lfkuj3qvdzu2jty2asq44cjhku
Both QR codes end up as the same size because, even though the first one is longer, it uses all-uppercase which lets it use the compact QR alphanumeric encoding. I believe the prefix is a good idea in general, so I am leaning towards the prefixed, all-caps option.
(the reason for the difference: address_detail.py uses to_ui_string(), and main_window.py receive tab uses the update_receive_qr() function which does more things)
Issue Analytics
- State:
- Created 5 years ago
- Comments:7
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
@markblundeberg Hahahaha. Did you actually stand a chance of getting that money? Hilarious.
Didn’t realize there are various ECC options for QR. Maybe we can see if the lib we use can do better?
Well – i can easily change the Qt code to generate whatever. So I guess the consensus is all screens do BITCOINCASH:QQBLABLA (all uppercase)??
Ah, makes sense. I imagine they would be.
Although honestly I’m amazed at how good QR already is and how well it works even when it’s dense and packed with info and the squares are small. (like has a huge long URL or something). I have never been unable to scan a QR code ever. But maybe i’m just lucky…