Two-way synchronization between Python-level objects and changes made directly through the Blender GUI

[yuxuanzhuang]

Currently, changes made directly in the Blender GUI do not automatically propagate back to the Python objects created and managed by GGMolVis. This leads to inconsistencies where the internal Python representation of molecular visualization parameters (e.g., positions, colors, materials) diverges from what is edited within Blender's interface.

Expected Behavior

When a user modifies a parameter—such as changing a material color—via the Blender GUI, the corresponding Python object's state should reflect this change, ensuring the Python-level "source of truth" remains accurate.

Current Behavior

Attributes stored in Python will override any edits made in the Blender GUI, such as changes to a molecule’s location, whenever a frame_change event is triggered.

Potential Solutions:

• Use Blender Handlers e.g. bpy.app.handlers.depsgraph_update_post to update Python objects.
• Consider making Blender the main source of truth, and let Python objects pull data on-demand.

[BradyAJohnston]

I have been refactoring some code recently with this in mind. My currently solution is that everything that needs to exist both in the UI and python, is stored only inside of Blender in a property.

For example, the properties like (average, subframes, interpolate, etc) which change how the trajectory is played back in the scene. For the python objects that use / set those values, they just attempt to set the value on the linked object instead.

class MolecularNodesObjectProperties(PropertyGroup):
    subframes: IntProperty(  # type: ignore
        name="Subframes",
        description="Number of subframes to insert between frames of the loaded trajectory",
        default=0,
        update=_update_trajectories,
        min=0,
    )

...

class Trajectory(MolecularEntity):
    @property
    def subframes(self) -> int:
        try:
            return self.object.mn.subframes
        except AttributeError:
            raise bpyd.object.ObjectMissingError(
                "Trajectory does not have a linked object. Cannot get subframes related to this object."
            )

    @subframes.setter
    def subframes(self, value: int) -> None:
        try:
            self.object.mn.subframes = value
        except AttributeError:
            raise bpyd.object.ObjectMissingError(
                "Trajectory does not have a linked object. Cannot get subframes related to this object."
            )

This way there is no synch to be performed, everything is stored on the objects themselves. We are slightly limited in terms of data types that can be stored as properties, but I have found that it works quite well.

The properties also can have an update function, so whenever you update them via the UI or code, it will update the 3D scene

[BradyAJohnston]

This does limit it that you can't edit / set these properties if there isn't an Object representation inside the 3D scene linked, but also it wouldn't make sense to change any of these properties without a visual 3D representation linked anyway.