This was a consequence of the work done in #106321, where this specific
'active in UI' case was not identified and properly handled.
Now, consider most ID usages from UI (editors) as 'weak links', i.e.
keep a reference to these IDs even if they are only indirectly used.
Note that missing weak links will not create placeholders if the source
data is not found in the library anymore on load. they are just silently
dropped.
Pull Request: https://projects.blender.org/blender/blender/pulls/122207
Advanced ID copying code can now take a `new_owner_id` ID pointer parameter,
and use it to set the relevant 'loopback' pointer to its owner ID by the
copy code itself.
Besides avoiding the need for all code copying embedded IDs to set the
loopback pointer themselves, this also means that `lib_id` copying code
itself does not need to use `IDWALK_IGNORE_MISSING_OWNER_ID` anymore.
This change is not expected to have any effect in current codebase.
In previous code, the owner ID info would not be available when
processing an embedded ID in two cases, and was incorrectly set to the
processed (embedded) ID instead:
1. When directly calling `BKE_library_foreach_ID_link` on an embedded ID.
2. When using recursive processing (`IDWALK_RECURSE`).
This commit mostly fixes both cases, by using `BKE_id_owner_get` to find
the owner ID when it is unknown.
There are some caveats here though: in a few specific cases (mainly ID
copying, and depsgraph ID copying), `BKE_library_foreach_ID_link` can be
called on embedded IDs which owner ID is not yet valid. In such case, a
new flag can be used to keep using the previous behavior
(`IDWALK_IGNORE_MISSING_OWNER_ID`).
Fixing the issue with copy code being unaware of the owner ID when
copying an embedded one should also be fixed, but this will be addressed
separately.
Note that as 'side efect', this commit also fixes a matching issue in
the `lib_remap` code, where the `IDRemap.id-owner` pointer would also
wrongly be set to the remapped embedded ID instead of its actual owner.
This change is not expected to have any effect in current codebase.
The idea is to allow iterating over e.g. all ID usages of a node from a
whole nodetree, using the same generic handling as existing 'whole ID'
`foreach_id` code.
This is necessary in some cases wher a sub-data needs to processed
independently from any 'owner ID', e.g. in some copy/paste handling.
This is a pre-requirement for proper fix of nodes copy/paste (see
e.g. #120103).
Pull Request: https://projects.blender.org/blender/blender/pulls/121018
This will allow for more control over which ID should actually be marked
as unused/to be deleted.
Also some general minor cleanups and refactor, most notably:
* Add a constructor to internal `UnusedIDsData` struct, which can
directly use the public `LibQueryUnusedIDsData` parameters struct.
* Add default values to trivial data in `LibQueryUnusedIDsData`.
No expected behavioral changes in this commit.
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.
Add a new `BKE_lib_query_unused_ids_amounts` to query expected amounts
of deleted IDs. This function does not tag IDs in main anymore.
Factorize most parameters (and output data) into a new struct
`LibQueryUnusedIDsData`.
Part of PR https://projects.blender.org/blender/blender/pulls/117304.
