Update macOS window title logic
Continuing on #40
Issues
- [ ] It seems like screen capture permissions are required in macOS 10.15+ (Catalina) for window titles to show up.
- See this issue for an example of a fix in Swift: https://github.com/lwouis/alt-tab-macos/issues/127
- There is a function CGRequestScreenCaptureAccess but I can't seem to access it from pyobjc.
- Edit: Looks like it wasn't added until macOS 11... (https://twitter.com/hrumarek/status/1345593659132051456)
- [ ] Need to rewrite parts so that it correctly handles the event-based approach.
- [ ] Need to combine event-based approach with polling since there's no event for 'window title changed' (only 'application changed').
- [ ] The Python docs state that multiprocessing
set_start_methods 'spawn' and 'forkserver' cannot be used with 'frozen' executables (as produced by PyInstaller). But 'spawn' became the default in Python 3.8, and the Python 3.7 default of 'fork' seems to make the new process crash... - [ ] More stuff from/comments on #40?
This pull request introduces 2 alerts and fixes 1 when merging 8c33a3e893b717d00f60a36980c7af802766109b into ff08c9ca7d102d76d3814b6302171ea54ca4cee1 - view on LGTM.com
new alerts:
- 2 for Unused import
fixed alerts:
- 1 for Module is imported with 'import' and 'import from'
Hey @xylix I made some progress here and seem to have tracked down the issue as to why window titles aren't being returned (screen recording permissions needed...)
Would you be interested in (and have the time) to continue work on this in the near future? I don't think it should be that much work now that I found the core issue.
This pull request introduces 6 alerts and fixes 1 when merging 9af99932aee107c4d44779f2d2284136d0269217 into ff08c9ca7d102d76d3814b6302171ea54ca4cee1 - view on LGTM.com
new alerts:
- 4 for Unused import
- 1 for Unused local variable
- 1 for Unreachable code
fixed alerts:
- 1 for Module is imported with 'import' and 'import from'
I might have time in a couple weeks... can't really promise I will, though. It is probably pretty doable in a few hours of work at this point.
On the fork / subprocess stuff: I've coded some other python multiprocessing and came across fork crashing things on macOS. Only being able to use fork with pyinstaller seems like a quite difficult limitation to work around 🤔
Understandable, just checking :)
tbh I think it might sense to make a release supporting both the new and old method (with the old as default, for the time being), so we can get something basic merged and go from there.
Re fork crashing when run by PyInstaller: I'm hoping that the Python docs are wrong/outdated here and will work fine, but it's a gamble.
@ErikBjare what's left to do here? What's breaking/needs more testing?
@iloveitaly Basically everything mentioned in the PR description.
I've abandoned work on this for now, as you provided an alternative method that wasn't as cumbersome to implement (but may still suffer from some of the same bugs).
Ah, I saw now that this would improve CPU and memory from frequently spawning a process.
I guess this needs to be revisited, but I'm personally prioritizing signing the app bundle, but it might be easier to do if we had this...
I'll think about it, unless you're willing to give it a shot @iloveitaly? :)
@ErikBjare I may have time to take a look! Do you remember why this didn't get merged / what was left to do here?
@ErikBjare any notes around what's left here to do?
@iloveitaly Only what's in the PR description I think. Basically testing it and making sure that permissions etc work.
@ErikBjare we should close this out too—the swift-based method solves all of these problems!