This commit ports the work of EchterAgo and cculianu from Electron-Cash,
to implement a new toolchain to scan qr codes.
Previously, on Linux and Win, we have been using zbar to access the camera
and read qrcodes; and on macOS we used CalinsQRReader (an objective-C
project by cculianu).
The new toolchain added here can use QtMultimedia to access the camera,
and then feed that image into zbar. When used this way, zbar needs
fewer dependencies and is easier to compile, in particular it can be
compiled for macOS.
The new toolchain works on all three platforms, with some caveats
(see code comments in related commits) -- so we also keep the end-to-end
zbar toolchain; but at least we can drop CalinsQRReader.
The related changes in Electron-Cash are spread over 50+ commits (several PRs and direct
pushes to master), but see in particular:
https://github.com/Electron-Cash/Electron-Cash/pull/1376
some other interesting links:
b2b737001c163224cf1f3b31e0fcb1eda015908ehttps://github.com/Electron-Cash/Electron-Cash/pull/1545052aa06c23
(well, not everything, only files in electrum/ (so e.g. not contrib))
See comment in setup.py.
E.g. we have been including the www/ folder in the tar.gz but have not been installing it
to site-packages. Now we do.
Or we have been including the kivy GUI files in the tar.gz but not installing them.
Now we do.
I like this because it simplifies setup.py and should be easier to reason about too.
should fix#7089 (at least when using the tar.gz)
- dnspython 2.0 requires cryptography 2.6 so we now always require that
(no longer a choice between cryptography and pycryptodomex)
- test_dnssec.py is deleted as it was testing the monkey-patch
related: #6538
Since #6014, pyaes is not really needed anymore.
As we currently require either one of pycryptodomex or cryptography,
even if pyaes is available, it will not be used.
We could strip it out completely from crypto.py...
In any case, pyaes is still pulled in by some hw wallet dependencies indirectly;
but the core library no longer depends on it.
so we don't need pyrcc5, which is not deterministic,
and so we don't need the submodule for the icons
based on electrumsv/electrumsv@bf8802c2eaf0bf75565b5423a95bcb85ec7eb781
Before, the user installation used the wrong directory
to store the application's icon resulting in the desktop
environment falling back to an ugly default icon. Now,
the correct icon is displayed in the menu.
"By default, apps should look in $HOME/.icons (for backwards
compatibility), in $XDG_DATA_DIRS/icons and in /usr/share/pixmaps
(in that order)."
https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html