E.g. when user opened .blend file and ifc filepath was pointing to a wrong destination, after they changed the filepath pset templates wouldn't reload.
There was a contradiction - modal operators were treated as special and were always creating new transactions (`is_top_level_operator = method == "MODAL"`), but those transactions were only closed if modal returned `FINISHED` or `CANCELLED`, so in most case previous transactions were just overridden, so IFC undo data was lost.
Ping @Moult just in case
Previously some of them were saved only for current .blend file, moving them to preferences will make it more consistent with usual Blender UX. If needed we'll be able to add some way to fine-grain them later.
There's also a temporary patch that's going to migrate old .blend-props to new preferences-props to make process less disruptive.
Previously, changing props.ifc_file had an update hook to reload
information about the IFC model. But this isn't always correct because
there are two situations:
1. The ifc_file path changed because you saved the file for the first
time or saved as, and this is merely recording a new saved path of the
existing file object.
2. The ifc_file path changed because the user manually changed it or
selected a new file. This could reference an entirely new file object.
This is dangerous because we can't trust anything anymore, including our
undo history.
So the new default situation is that there is no magic hook. If you
change props.ifc_file, that's all it changes ... just a path stored in
Blender with not much significance.
If the user runs select_ifc_file to explicitly relink the file, it now
explicitly purges in that situation and clears the undo history.
Basically now behaviour is explicit, not using magic hooks.
Previously cache_dir was located under site-packages, which is managed
by blender and could be read-only. Now location defaults to eg.
~/.cache/bonsai or equivalent location on other platforms. See #5564
Note this adds a dependency on the platformdirs python module
I can't explain this one so I'm pretty embarrassed to commit this, but
it crashes (see situation in #5799) on my machine and I can't recreate
it outside this scenario. In any case I think as a general strategy we
should:
1. Minimise reliance on msgbus
2. Msgbus listeners themselves should be wary of invalid state (e.g. if
object is now unlinked)
3. Not clear listeners (don't overreach)
Now it's stored as a collection property in the project properties, so in the most cases we delegate to Blender to ensure it's handled properly on undo and redo.
Previously transaction was never finished and therefore is_top_level_operator would never be triggered (without restarting project) making any IFC undo useless.
Previously it wsan't finishing transaction therefore:
- it was possible to undo ifc changes in the last step that had an error
- since transaction was never finished, IfcStore.current_transaction was never cleared and therefore is_top_level_operator will be never be triggered for the next operators, so new transactions are never created breaking undo for any further ifc changes.
Now user can try to undo the last action to save the file.
OperationData was always including guid key, so guid_map[None] was pointing to some object (typically a style). Also covered by rebuild_element_maps in the most cases.
Andrej730