There is still the issue that we have no replacement for the `scene_update_pre/post` handlers.Depends on: https://developer.blender.org/D3978
Currently I know of 2 main scenarios this was useful for:
- React to specific changes in the scene. A better way to do this would be to support callbacks to specific property changes, however we don't have this yetThe `depsgraph_update_pre/post` handlers are useful when one is monitoring specific properties in Blender.
- Communicate with other threads/processes over a longer period of time (e.g. all the time Blender is running). Another thread could listen to incoming messages and forward the required action to the main thread, so that it can change Blender data (which should not be done at arbitrary points in time in another thread)To fully replace the behavior of the `scene_update_post/pre` handlers we need more though.
All other caThis patch proposes can probably be handled by modal operators alreadya new `bpy_extras.callback_utils` module with two new functions (whose name can still change).
I know there is a plan to implement some kind of timer that allows one to run code in a specific interval- `set_interval(function, interval)`: This registers a callback that should be called every `interval` seconds. When the function returns `True`, but personally I don't see a real use case for itit will run again in the next interval. Maybe someone can enlighten meOtherwise it will be unregistered automatically.
Also it is possible to have both- `run_in_main_thread`: Sometimes it is useful to run a separate thread in Blender (e.g. for a simple server or for Python debugging). Currently there is no reliable way to change any Blender data from a separate thread. Using this utility function, addon developers can register a callback that will be executed one time, this callback and the timer that will be implemented laterwhen Blender is in the right state.
IMO the main problem with the `scene_update_post` handler was its namenternally this behavior is implemented using a new `_always` handler that should maybe not be part of the official API. The behavior of it can still be archieved by registering a function with zero interval. So by changing the name to `always` we can make it very clear thaFor simplicity I think it is a good idea to implement this callback will be executed very oftenfunctionality in Python. It is the responsibility of addon developers to use thisThe `always_handler` functionality wisely so that it does not slow down Blender notable tries to be as fast as possible in the common case.