This adds a version of `BKE_id_new_nomain` that takes the ID type parameter as
template argument. This allows the function the return the newly created ID with
the correct type, removing the need to use `static_cast` on the call-site.
To make this work, I added a static `id_type` member to every ID struct. This
can also be used to create a similar API for other id management functions in
future patches.
```cpp
// Old
Mesh *mesh = static_cast<Mesh *>(BKE_id_new_nomain(ID_ME, "Mesh"));
// New
Mesh *mesh = BKE_id_new_nomain<Mesh>("Mesh");
```
Pull Request: https://projects.blender.org/blender/blender/pulls/138383
Note: This commit is essentially non-behavioral change, expect in some
fairly rare edge cases.
This commit does a few things:
* Move the whole BKE_main_namemap code to modern C++.
* Split API calls to work with the global namemap, or the local ones.
* Simplify and make the code easier to follow and understand.
* Reduce 'default' memory usage by using growing BitVector for numeric
suffix management, instead of a fixed 1K items.
* Fix inconsistent handling of 'same base name and numeric suffix,
different name' issues (e.g. 'Foo.1' and 'Foo.001'), see
`re_create_equivalent_numeric_suffixes` new unittest.
* Fix completely broken handling of `global` namemaps. This was
(probably!) OK so far because of their currently very limited
use-cases.
It also adds a few minor improvements to existing behavior (essentially
in exotic rare edge cases):
* Names that get too long are now only shortened by one char at a time,
trying to modify the requested base name as little as possible.
* Names that are short, but for which all the manageable numeric suffixes
are already in use, are extended with an (increasing) number, instead
of being shortened.
This work also allowed to detect a few (apparently harmless?) bugs in
existing code, which have been fixed already in 4.4 and main, or in this
commit as well when they depend on changes in namemap code itself.
About performances: This commit introduces a minor slow-down. Some tests
heavily relying on this code (like `bl_id_management` and `blendkernel`
e.g.) get slightly slower (resp. about 1% and 5%). This seems to come
mostly from the added complexity to handle correctly multiple different
names with the same base and numeric suffix value ('Foo.1' and
'Foo.001', but also in the global namemap context where IDs from
different libraries can have the same name).
Pull Request: https://projects.blender.org/blender/blender/pulls/135199
Move `Library.runtime` to be a pointer, move the related
`LibraryRuntime` struct to `BKE_library.hh`. Similar to e.g.
Mesh.runtime, that pointer is expected to always be valid, and is
allocated at readtime or when creating a new Library ID.
Related smaller changes:
* Write code now uses standard ID writing codepath for Library IDs too.
* Runtime pointer is reset to nullptr before writing.
* Looking up a library by its absolute path is now handled through a
dedicated utils, `search_filepath_abs`, instead of using
`BLI_findstring`.
Pull Request: https://projects.blender.org/blender/blender/pulls/134188
Reset the 'hierarchy index' runtime `temp_index` value for all library IDs.
This prevent the assert to be triggered when trying to rebuild libraries
hierarchy and there are some orphaned (i.e. not used by anything) library IDs
around.
A few ID types are considered as 'never unused' in Blender (UI related
ones, the Libraries and the Scenes). Local IDs of this type are always
considered as used, even if no other ID links to them.
This was previously fairly weekly defined and implemented (mainly in the
writefile code and the 'tag unused' libquery functions).
This commit formalize this characteristic of ID types by adding a new
`IDTYPE_FLAGS_NEVER_UNUSED` flag, and using this in the few places in
the code that handle unused IDs.
So far, when deleting a library (either explicitely, or through e.g.
relocation), its dependencies would get a `nullptr` parent, and
therefore become 'directly used' libraries.
This commit adds a new util to rebuild the libraries hieararchy, and
calls it when a Library ID is deleted.
NOTE: While logic is somewhat similar to what liboverride resync does to
sort the libraries by indirect levels
(`lib_override_libraries_index_define`), there are some key differences
here, notably the fact that if a library has a valid `parent` pointer,
it is not replaced, even if a 'better' parent (less indirect library)
could be found.
This data was 'hidden' away in a util in
`lib_query.cc`, which made it hard to discover and keep up-to-date.
However, as shown by e.g. #108407, critical low-level features in ID
management code, such as remapping, now rely on this information being
valid.
Also simplify `BKE_library_id_can_use_filter_id` and
`BKE_library_id_can_use_idtype` to make them more generic, relying on
IDTypeInfo to retrieve IDtype-specific info.
No behavioral changes expected here.
Extract:
- Sculpt filter types from the Sculpt menu. Some of these types use a
custom label, different from those defined in the operator RNA,
which was never extracted.
- "Today" and "Yesterday" from the file browser modification date.
- All name_plural from IDs, as these are used in the UI to list which
data block is to be removed, when calling outliner.orphans_purge.
Disambiguate:
- "Area", meaning the measurement of a surface as opposed to a place.
Some messages reported by Satoshi Yamasaki in #43295.
Pull Request: https://projects.blender.org/blender/blender/pulls/113912
The `Library.tag` data is supposed to be runtime only, so needs to be
cleared when reading data from blendfile.
This fixes the 'need resync' status of a library staying around forever
once set, annoying visual warning in the Outliner.
The `lib_link` callback cannot always be fully replaced/removed, as in
some case it is also doing some validation checks, or data editing based
on the result of lib_linking internal ID pointers.
The callback has been renamed for that purpose, from `read_lib` to
`read_after_liblink`. It is now called after all ID pointers have been
fully lib-linked for the current ID, but still before the call to
`do_versions_after_linking`.
This change should not have any behavioral effect. Although in theory
the side-effect of this commit (to split lib linking itself, and the
validation/further processing code) into two completely separated steps
could have some effects, in practice none are expected, and tests did
not show any changes in behavior either..
Part of implementing #105134: Removal of readfile's lib_link & expand code.
The `expand` callback is 'trivial' to replace, since it is only iterating
over ID pointers and calling a callback.
The only change in behavior here is that some pointers that were not
processed previously will now be.
In practice this is not expected to have any real effect (usually
the IDs used by these pointers would have been expanded through other
usages anyway). But it may solve a few corner cases, undocumented issues
though.
Part of implementing #105134: Removal of readfile's lib_link & expand code.
This commit adds a new option flag to the lib_query foreach_id code,
which will make deprecated ID pointers to be processed as well.
NOTE: Currently there is no report to the callbakcs about the fact that
it is processing a deprecated ID. This can be easily added later if it
becomes necessary.
Part of implementing #105134: Removal of readfile's lib_link & expand code.
Also see #103343.
Couldn't move two files yet:
* `softbody.c`: The corresponding regression test fails. It seems like the
conversion to C++ changes floating point accuracy, but it's not clear where that happens exactly.
* `writeffmpeg.c`: Is a bit more complex to convert because of the static array in `av_err2str`.
Pull Request: https://projects.blender.org/blender/blender/pulls/110182
