MolecularNodes: Fixing Entity Type Discrepancies

Hey guys! Today, we're diving deep into a fascinating discussion surrounding the MolecularNodes addon for Blender, specifically focusing on some inconsistencies spotted within the mn.entity_type property. This property plays a crucial role in defining the type of molecular entity being represented, such as molecules, ensembles, or densities. Let's break down the issues, proposed solutions, and the broader implications for MolecularNodes' usability and robustness. This discussion was started by BradyAJohnston and MolecularNodes, so let's give them a big thanks for bringing these important points to light!

Understanding the mn.entity_type Discrepancies

The core of the problem lies in the inconsistent usage and definition of the entity_type property. As an EnumProperty defined in ui/props.py, it's intended to offer a clear and controlled way to categorize molecular entities within Blender. Currently, it includes five potential values: molecule, ensemble, density, md, and md-oxdna. These values neatly align with the enums specified in the EntityType enum class located in entities/base.py. However, the actual application of these enums reveals a few cracks in the system.

The Default Value Dilemma

A key point raised is the behavior of Blender EnumProperty when no default value is explicitly defined. In such cases, Blender automatically assigns the first enum value as the default – which, in this case, is molecule. While this might seem like a minor detail, it can lead to unintended consequences if entities are not correctly assigned their specific types during creation. The suggestion to introduce an explicit None type as the default is brilliant! It would act as a clear indicator of uninitialized entity types, making it easier to spot and rectify errors early on.

StarFile and CellPack Enigmas

The discussion then zeroes in on the Ensemble entity, which encompasses two derived entities: StarFile and CellPack. Here's where things get particularly interesting. In the create_object function for StarFiles, the entity_type is being set using this line of code:

self.object.mn["entity_type"] = "star"  # type: ignore

This line, as pointed out, is problematic for a couple of reasons. First, when using dictionary-style access (object.mn["entity_type"] = ), Blender expects the index of the enum value, not the string representation. Second, even if the code used the correct syntax (object.mn.entity_type = "star"), the value "star" isn't a valid member of the entity_type enum, resulting in a TypeError. This means that StarFile entities are likely being incorrectly classified as molecule (the default).

CellPack objects face a similar plight. The entity_type isn't even being set after object creation, leaving them to default to molecule as well. This further underscores the need for a more robust and consistent approach to entity type assignment.

UI Exposure and Unreachable Code

The MolecularNodes UI, specifically the Object panel, allows users to reconfigure the entity_type via layout.prop(object.mn, "entity_type"). While this might seem like a useful feature, it exposes the underlying issues with the enum. The code also contains checks for pdb and star values, which, as we've established, are not part of the enum and thus will never be triggered. This means that certain UI elements, such as ui_from_node (which is intended to be shown in the case of `