- we were already
- statically declaring "NSCameraUsageDescription" in the Info.plist
- this used to be enough in the past
- codesigning with an entitlements.plist that declares "com.apple.security.device.camera"
- I believe this is required for notarization to pass for an app that declares "NSCameraUsageDescription".
- previously this was enough to access the camera IIRC
- in any case, if the user goes into "System Preferences">"Security & Privacy", they can manually modify permissions there
- now with this commit, we on-demand trigger at runtime the OS permission prompt
- making it much easier for users to actually use the camera
- note: if you run via the Terminal, e.g. `$ $HOME/Desktop/Electrum.app/Contents/MacOS/run_electrum`,
then it will be the Terminal app that requires the camera permission. If you run by double-clicking Electrum.app,
then Electrum.app will be the "app" that requires the camera permission.
- `$ tccutil reset Camera` can be used to clear permissions for all apps (back to the Qt::PermissionStatus::Undetermined state)
ref https://doc.qt.io/qt-6.5/qcoreapplication.html#requestPermission-1
The user should still be able to open the Preferences dialog, despite the camera functionality being broken.
see https://github.com/spesmilo/electrum/issues/9949
```
6.36 | E | gui.qt.exception_window.Exception_Hook | exception caught by crash reporter
Traceback (most recent call last):
File "electrum\gui\qt\main_window.py", line 2672, in settings_dialog
File "electrum\gui\qt\settings_dialog.py", line 229, in __init__
File "electrum\gui\qt\qrreader\__init__.py", line 96, in find_system_cameras
File "<frozen importlib._bootstrap>", line 1360, in _find_and_load
File "<frozen importlib._bootstrap>", line 1331, in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 935, in _load_unlocked
File "PyInstaller\loader\pyimod02_importers.py", line 450, in exec_module
File "electrum\gui\qt\qrreader\qtmultimedia\__init__.py", line 28, in <module>
File "<frozen importlib._bootstrap>", line 1360, in _find_and_load
File "<frozen importlib._bootstrap>", line 1331, in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 935, in _load_unlocked
File "PyInstaller\loader\pyimod02_importers.py", line 450, in exec_module
File "electrum\gui\qt\qrreader\qtmultimedia\camera_dialog.py", line 32, in <module>
RuntimeError: PyQt6.QtMultimedia cannot import type '���d�⌂' from PyQt6.QtCore
```
There was no ability to read qr codes contained in image files. This
could lead to confusion in some contexts, as `on_file_input()` of
ScanQRTextEdit will read the whole content of the file (instead of
looking for qr codes). The revealer plugin for example generates png
files containing qr codes and uses the `ScanQRTextEdit` to get user
input, for the user it would seem logical to click on 'Read from file'
to load the generated file, however this will result in the wrong data
being loaded. Having the option to explicitly load a QR from file makes
this clear. Also it seems useful, especially considering reading QR from
screenshots doesn't work on wayland.
The qtmultimedia-based qrreader has the concept of "strong_count":
before the scanner returns a decoded qr code result, it waits until
it has seen at least "strong_count" (e.g. 10) frames in which the qr code was seen and successfully decoded.
I think the idea might have been to reduce false positives, mis-decoding qr codes from bad frames.
However in practice it makes scanning even moderately sized qr codes really difficult for the user:
it takes several seconds (at least on my laptop cam) to obtain enough "clear" frames that count into the strong_count.
So I am lowering the strong_count to 2, down from CAMERA_FPS/3,
which makes it easier to scan, and I still haven't seen false positives even with this value.
A new config API is introduced, and ~all of the codebase is adapted to it.
The old API is kept but mainly only for dynamic usage where its extra flexibility is needed.
Using examples, the old config API looked this:
```
>>> config.get("request_expiry", 86400)
604800
>>> config.set_key("request_expiry", 86400)
>>>
```
The new config API instead:
```
>>> config.WALLET_PAYREQ_EXPIRY_SECONDS
604800
>>> config.WALLET_PAYREQ_EXPIRY_SECONDS = 86400
>>>
```
The old API operated on arbitrary string keys, the new one uses
a static ~enum-like list of variables.
With the new API:
- there is a single centralised list of config variables, as opposed to
these being scattered all over
- no more duplication of default values (in the getters)
- there is now some (minimal for now) type-validation/conversion for
the config values
closes https://github.com/spesmilo/electrum/pull/5640
closes https://github.com/spesmilo/electrum/pull/5649
Note: there is yet a third API added here, for certain niche/abstract use-cases,
where we need a reference to the config variable itself.
It should only be used when needed:
```
>>> var = config.cv.WALLET_PAYREQ_EXPIRY_SECONDS
>>> var
<ConfigVarWithConfig key='request_expiry'>
>>> var.get()
604800
>>> var.set(3600)
>>> var.get_default_value()
86400
>>> var.is_set()
True
>>> var.is_modifiable()
True
```
SomberNight