## 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_OT_paths_clear~~** rB478446e3a45c5eff7aed238b92e5d3d7cf671c7a
- **~~POSE_OT_paths_calculate~~** rB478446e3a45c5eff7aed238b92e5d3d7cf671c7a
- **~~POSE_OT_paths_update~~** rB478446e3a45c5eff7aed238b92e5d3d7cf671c7a
- ~~POSE_OT_autoside_names~~ rBc7bbcfe95444e730eacf655fd982f5091d5e2ff6
- ~~POSE_OT_rotation_mode_set~~ rB3b9b6a80ba6311281bb90e2a2e63a8c34a0b575d
- ~~ARMATURE_OT_armature_layers~~ rB3a8b56ce24c9228a885d3c44f4c22d90be04ae4c
- ~~POSE_OT_bone_layers~~ rBbb7f4f5714430beda44403f0bd75c368e8f86a39
- ~~**POSE_OT_hide**~~ rBc9d1082a2c17162ea6d23415e3560dabfc6e22e1
- ~~**POSE_OT_reveal**~~ rBc9d1082a2c17162ea6d23415e3560dabfc6e22e1
- ~~POSE_OT_quaternions_flip~~ rB7560aabf71dd4c7687ff0110e722287d66358bbd
**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
- 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). (done rBc462c43c1a05).
- ~~POSE_OT_select_hierarchy~~ rBd95bb08f395ace3fdfed71058658b7acef458ded
- ~~POSE_OT_visual_transform_apply~~ rB4376bb64054cb8de0b71f85d4faa832d4ec736cd
- **~~POSE_OT_copy~~** - [To be ported by @aligorith] (*1)
- **~~POSE_OT_paste~~** - [To be ported by @aligorith] (*1)
- **~~POSE_OT_transforms_clear~~** rBe0478ae92fbefbc648bfb5a5f8370a53af1c6679
- ~~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_OT_select_parent~~ rBdcf1210c44cb1e46bf387f326c5ee9daa2a53004