Blender-Auto-Dark-Mode
Blender-Auto-Dark-Mode copied to clipboard
Listen for theme changes instead of polling
Currently, the add-on polls every 10 seconds for changes to the system theme. Obviously, it would be better to instead listen for the system to notify the add-on, to increase responsiveness and reduce unnecessary activity. Right now there are a few challenges/blockers:
- The darkdetect library requires extra dependencies to listen for changes on macOS, which Blender fails to import because the wheels are universal binaries: https://projects.blender.org/blender/blender/issues/125091
- I have tried the workaround of renaming the wheels to the current architecture as suggested in that issue discussion, and they still fail to import in Blender with an error about a circular dependency in the
objcpackage (there is no circular dependency, it works fine outside of Blender). Unclear if this error is caused by renaming the wheels or something else.
- I have tried the workaround of renaming the wheels to the current architecture as suggested in that issue discussion, and they still fail to import in Blender with an error about a circular dependency in the
- darkdetect’s listener requires multithreading with a thread that runs continuously & independently of the main thread, which Blender’s documentation warns against: https://docs.blender.org/api/current/info_gotcha.html#strange-errors-when-using-the-threading-module (quote from the docs: “So far, no work has been done to make Blender’s Python integration thread safe, so until it’s properly supported, it’s best not make use of this.”) There might be some way to do this safely, but I’m not experienced with multithreading in Python, and I can’t test anything because of the dependency issue.
If anyone has a working solution or workaround I would very much appreciate your suggestions or pull requests.
I found https://docs.blender.org/api/current/bpy.app.timers.html#use-a-timer-to-react-to-events-in-another-thread regarding the second issue:
You should never modify Blender data at arbitrary points in time in separate threads. However you can use a queue to collect all the actions that should be executed when Blender is in the right state again. Pythons queue.Queue can be used here, because it implements the required locking semantics.
You'd still need a timer, but maybe it could be on a shorter interval, since it would just be polling a queue and not shelling out to gsettings each time.