There was too much code duplication - there still is a bit...
- in some places buttons had text "Read QR code with camera", in others it was "Read QR code from camera"
- 63c224cb53 added a "on_qr_from_file_input_btn"
input method, which was not added everywhere.
- was missing in add_qr_input_combined_button and in editor_contextMenuEvent
- 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
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.
RunCoroutineDialog has a run() method that blocks the thread
without blocking the GUI (using exec), and a Cancel button
that cancels the coroutine.
main_window.run_coroutine_dialog() is a wrapper that returns
the coroutine result and may raise exceptions.
BlockingWaitingDialog was removed is transaction_dialog,
where it was not particularly useful.
user complained:
> when you want to sweep an address. it's very unclear to me as a noob who is getting the money
> might want a little picture with an arrow to show which direction the funds are going
- without this, in send tab paytoedit, try_payment_identifier will get called and it will error
df1b9a223c/electrum/gui/qt/paytoedit.py (L153)
- also, in all text fields this used to result in clearing the current text (but now it is kept instead)
- no semantic changes, only moving code
- the change in qt/util.py is to avoid GC issues
- due to moving code, the group was moving out of scope and getting GC-ed,
as we only keep a reference to the vbox
(idea from 263fb2ba33 )
Note that HTLCs must not be cancelled after the funding transaction
has been broadcast. If one want to cancel a swap once the funding
transaction is in mempool, one should double spend the transaction.
The input_qr_from_screenshot functionality is broken on some Linux machines:
on some machines, `screen.grabWindow(0)` returns an all-black image.
In such cases, instead of telling the user "No QR code was found on the screen",
we will tell them "Failed to take screenshot".
To test:
`QApplication.instance().primaryScreen().grabWindow(0).save("/home/user/wspace/tmp/pic2.png", "png")`
Tested on:
- machine 1:
- ubuntu 22.04, gnome, wayland
- pyqt.version: 5.15.9
- qt.version: 5.15.2
=> gets all-black image for screenshot
- machine 2:
- manjaro, kde, x11
- pyqt.version: 5.15.9
- qt.version: 5.15.8
=> screenshot works
I guess it might be due to x11 vs wayland.
