- Initial upload, this only works in basic case - editing a button & manipulators updates other areas that use the same properly.
- Existing notifier system is disabled for property updates.
This mostly works but causes some issue where properties should update the 3d view (viewport integration is currently undefined). - Using name "message bus" at the moment (since this is a term often use for publish-subscribe systems), helps differentiate with existing notifier system.
- Updates viewport respond to changes in types instead of individual properties - to avoid too fine-grained subscriptions for every property.
- Allocations could be moved into a mempool later on, currently its simple not to.
- Struct names and API's are a bit confusing, this is more complicated then I'd like, but seems necessary at the moment if we want to have a generic message type that sSupports multiple types via polymorphic structs.
Python API example (this area is work in progress):
Open Topics
- Where to store the message-bus(s) so we can show the same scene at different times - without messages being causing updates in the wrong place.
(having it subscribe to all properties seems unreasonable). - We could use more general subscriptions here - everything from Mesh/Camera/Lamp's for example - and ignore the properties. - What conventions to use for message-subscription life-times? For example - an addon may wan't to subscribe to changes to a property, even after a new file is loaded (we have this ability for bpy.app.handlers - called persistent handlers).