Viewing changes necessarily sets object colours and switches the
viewport to object colouring. Previously most other operations switched
the viewport 'back' to material colouring. This was an annoyance for
users whose workflow makes use of manual object colouring.
Now only operators that reload the model (revert, switch and merge), the
refresh button, and attempting to view changes with the current revision
switch to material colouring.
Couldn't find if we actually use it anywhere in the code but better to keep it safe, especially because it's exposed to Python and by accident user might provide some too bit integer instead of a string.
Noticed that prop_value could be other types besides str (e.g. int when using context menu on UIList item) and we can skip them to avoid redundant api calls.
By accident noticed that `declaration_by_name(-1)` crashes python. If we use size_t it will just throw an error like below
NotImplementedError: Wrong number or type of arguments for overloaded function 'schema_definition_declaration_by_name'.
Possible C/C++ prototypes are:
IfcParse::schema_definition::declaration_by_name(std::string const &) const
IfcParse::schema_definition::declaration_by_name(size_t) const
`repo.path` is always setup using current platform type of slashes since it's normalized by get_path_dir but when we pass a path to index.add it's not normalized leading to errors
As on first iteration it may remove only unused material sets and on the next iteration it will be able to remove IfcMaterials that were not used anywhere else besides those material sets.
It wasn't working anymore after 27a2c94. Importing IFC file as just geometry should be a separate option from 'should_start_fresh_session' and I've added it as 'import_without_ifc_data' property during project load (now both options are also available for users in project load dialog - https://i.imgur.com/Fvbv4Dy.png)