Philipp Oeser
9fc000cc6f
Mistake in own rBb6a35a8153c3 which caused code to always recurse into bone hierarchies (no matter which collapsed level an armature was found). This led to bone counts always being displayed even outside a collapsed armature (e.g. if an armature was somewhere down a object or collection, the collapsed object or collection would show this bonecount). This is inconsistent with other data counting in the Outliner, e.g. vertexgroups or bonegroups do have their indicator at object level, however the counter only shows if `Vertex Groups` or `Bone Groups` line shows (so if the object is not collapsed). And this also led to the bug reported in T101946 which was that the bone counts would be treated as collections when further down a collapsed hierarchy. Background: The whole concept of `MergedIconRow` is based on the concept of counting **objects types or collectinons/groups**. If other things like overrides, vertexgroups or bonegroups are displayed in a counted/ merged manner, then these will always be counted in the array spots that are usually reserved for groups/collections. But for things this is not a problem (since these are only displayed below their respective outliner entry -- and will never be reached otherwise). So to correct all this, we now only recurse into a bone hierarchy if a bone is at the "root-level" of a collapsed subtree (direct child of the collapsed element to merge into). NOTE: there are certainly other candidates for counted/merged display further up the hierarchy (not just bones -- constraints come to my mind here, but that is for another commit) Maniphest Tasks: T101946 Differential Revision: https://developer.blender.org/D16319