Notes about notation

• Excluded from Multi-Object Editing - Everything in (parentheses)
• Priority items (i.e. for Spring migration) - Everything in bold

Notes about approach (25/5)

Talking with the animators here in the studio, it seems that most of the time, animators don't actually want most tools to work with "full" multi-object posing behaviour. So, what we might do here instead is that by default, pose operators still work in the old (single active object) way, with just a few specific exceptions added on a case-by-case basis (as/when desired by animators). Examples here include mouse select tools and basic loc/rot/scale transform tools. Many other tools may be best left as single-object for now.

pose_edit.c

• POSE_OT_paths_clear
• POSE_OT_paths_calculate
• POSE_OT_paths_update
• POSE_OT_flip_names
• POSE_OT_autoside_names
• POSE_OT_rotation_mode_set
• ARMATURE_OT_armature_layers
• POSE_OT_bone_layers
• POSE_OT_hide rBc9d1082a2c17162ea6d23415e3560dabfc6e22e1
• POSE_OT_reveal rBc9d1082a2c17162ea6d23415e3560dabfc6e22e1
• POSE_OT_quaternions_flip rB7560aabf71dd4c7687ff0110e722287d66358bbd

pose_group.c

Note: With these ones, we made the decision to only allow supporting the "active object" as displayed in the UI (where these operators appear). As a result, multi-object editing doesn't actually function with these operators. But also, no further changes are required

• (POSE_OT_group_add)
• (POSE_OT_group_remove)
• POSE_OT_group_unassign
• POSE_OT_group_assign
• (POSE_OT_group_move)
• (POSE_OT_group_sort)
• POSE_OT_group_select
• POSE_OT_group_deselect

pose_lib.c

• Most operators here are fine, as they don't use the context iterators to loop over bones, and it doesn't make sense to apply Pose Libraries (defined for a single armature) across multiple selected armatures.
• The one exception here is the POSELIB_OT_pose_add operator, as it needs to use the Whole Character (selected) KeyingSet to determine what bones get added to the library. The one problem with this though is that this keyingset uses the context.selected_pose_bones iterator, which includes bones from multiple active armatures. We'll need a solution here to allow restricting keyingsets without also losing all filtering capabilities in the iterator (i.e. we'd lose the name-filtering used to determine what bones should/shouldn't get included)

• POSELIB_OT_action_sanitize
• POSELIB_OT_apply_pose
• POSELIB_OT_browse_interactive
• POSELIB_OT_new
• POSELIB_OT_pose_move
• POSELIB_OT_pose_remove
• POSELIB_OT_pose_rename
• POSELIB_OT_unlink

pose_select.c

• VIEW3D_OT_select_border
• VIEW3D_OT_select_circle
• POSE_OT_select_all
• POSE_OT_select_mirror
• POSE_OT_select_constraint_target
• POSE_OT_select_linked
• POSE_OT_select_hierarchy
• POSE_OT_select_grouped

pose_transform.c

• POSE_OT_visual_transform_apply rB4376bb64054cb8de0b71f85d4faa832d4ec736cd
• POSE_OT_armature_apply
• POSE_OT_copy - [To be ported by @Joshua Leung (aligorith)] (*1)
• POSE_OT_paste - [To be ported by @Joshua Leung (aligorith)] (*1)
• POSE_OT_transforms_clear rBe0478ae92fbefbc648bfb5a5f8370a53af1c6679
  • POSE_OT_loc_clear
  • POSE_OT_rot_clear
  • POSE_OT_scale_clear
• POSE_OT_user_transforms_clear rB4529192157135bfdc5f5fb48c798f7b205f25570

(*1) Copy/Paste - These currently don't have any problems working with multi-objects (i..e you don't get wrong bones getting copied/pasted). The only problem is that you can only from and paste to whatever armature is active at the time the operator is invoked. (So, you can copy a pose from one armature and paste it into another without leaving pose mode, as long as both objects are in posemode). So, currently marking these as working.

pose_slide.c

• NLA_OT_bake
• POSE_OT_breakdown / POSE_OT_relax / POSE_OT_push - [To be ported by @Joshua Leung (aligorith)]
• POSE_OT_propagate - [To be ported by @Joshua Leung (aligorith)]

Others

• POSE_OT_ik_clear
• POSE_OT_ik_add
• POSE_OT_constraints_clear
• POSE_OT_constraints_copy
• POSE_OT_constraint_add_with_targets
• POSE_OT_select_parent rBdcf1210c44cb1e46bf387f326c5ee9daa2a53004