The light module (PR #5452) defined its own EnumPropertySearch class with
bl_idname = "bim.enum_property_search", conflicting with the main
BIM_OT_enum_property_search in operator.py. The light module's version
lacked should_click_ok and other properties, so whichever class registered
last caused an AttributeError when helper.py tried to set op.should_click_ok.
Remove the duplicate EnumPropertySearch and SetEnumProperty operators from
light/operator.py and __init__.py entirely, and replace the local
prop_with_search/get_enum_items helpers in light/ui.py with an import of
the canonical prop_with_search from bonsai.bim.helper.
Generated with the assistance of an AI coding tool.
The light module's EnumPropertySearch operator was using the same
bl_idname ("bim.enum_property_search") as the main BIM_OT_enum_property_search
in operator.py, but only defined prop_name and search_term properties,
lacking should_click_ok and others. Whichever class registered last would
overwrite the other, causing an AttributeError when helper.py tried to
set op.should_click_ok on the stripped-down version.
Renamed the light module operator to "radiance.enum_property_search" and
updated the matching call in light/ui.py.
Generated with the assistance of an AI coding tool.
To avoid error:
File "/home/falken10vdl/.config/blender/5.0/extensions/.local/lib/python3.11/site-packages/bonsai/bim/module/light/list.py", line 33, in <module>
class MATERIAL_UL_radiance_materials(bpy.types.UIList):
^^^
NameError: name 'bpy' is not defined
Cheers!
Previously, sort, reverse list, and join functionality was implemented
as special cases in Bonsai itself. Given that it has usecases
(especially in material lists, but any sort of list applies) I've moved
this function into the IOS formatting language.
The IOS formatting language previously wasn't capable of this, but the
awesome addition by @falken10vdl made the formatting language accept
queries inline, so that means it can handle lists. I also added tests
for all the new functions and expression syntax (+-*/ operators).
I simplified the code that gets the evaluated text literal - previously
it seems to call format() multiple times.
Previously, copy attribution was coupled with text editing. This meant
that you couldn't just do something like change the font or alignment
without also affecting literals. Now like most apps you can just select
bunch of text and change font size etc, using the same UI look and feel
that copying attribute has when editing attributes.
This refactor also removes the need for explicit props tracking each
possible attribute to copy, and the settings collection group. Bulk
applying is now done in core with no calls to UI.
Turned out `aud` module we had in our makefile had nothing to do with Blender built-in `uad` module 🫣
So no need to install anything from PyPI since this module is generally available in Blender
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.