This isn't complete yet, but it hopefully demonstrates a preferred
implementation:
* Logic in core, not operator
* Loop done in core, without needing to call other core functions, so
the overhead of enabling and disabling editing per object is removed. No
more Blender logic, just straight editing in IFC.
* Reuse existing function to grab text attributes instead of
reimplementing it twice.
* Remove dead code, there seems to be a function
apply_to_selected_objects which was completely unused and duplicated
code twice.
Fix issue where selected text annotations remained in editing mode after
applying changes. Now properly restores original editing state for each
selected object.
Sync children was a bit odd because it's not actually an "array
parameter" per se, just a way to regenerate. It's now an operator.
There was a deeper issue I encountered where the way arrays work is that
they duplicate the parent element. (first encountered in e51d2d )
However, the duplication code has special array handling too. To avoid
issues with this cyclical coupling the previous solution was to
reimplement object duplication (with all sorts of pitfalls that has).
Now, I've tried to decouple it further by clearing all array psets prior
to any change, and readding the pset after everything has been
regenerated.
This can be improved upon but I don't feel confident until there is more
comprehensive test coverage for the duplicate operator.
This has a few advantages:
- The collection logic is centralised
- The collection logic is configurable based on the collection mode
- The name is not hardcoded
This reimplements @theoryshaw 's commit 9adbd4 but has a few upgrades:
- Considers all parent / child relationships, not just aggregates
- Puts business logic in core where it belongs and tool code in tool
- Uses existing utils where possible like get_decomposition
- Does not use name based collection checking which is fragile
- Reuses tool.Collector
- Makes container assignment handle the API's capability to do things
in bulk instead of one by one in a loop, so it's faster
- Tests
This is a cool idea, but users have all sorts of Blender collection
strategies and I think it's a good idea for Bonsai code to just touch
Bonsai's stuff and leave everything else. Separate functionality can be
built for non-Bonsai workflows and preferrably in a more discoverable
way than in individual Bonsai features.
When joining objects with mismatched representation types, deselect and
skip incompatible objects rather than canceling the entire operation.
This allows users to join compatible objects even when the selection
includes incompatible ones.
Dion Moult