To be honest, I'm not familiar with the transform operator code at all. Searching through it I found a comment mentioning a similar 'one handle stuck' problem (seemingly with curve objects), and some kind of hack to avoid that in that case.

Not critical at all. The goal is to select just two (or more) e.g. right side handles of two different keyframes of diffrent fcurves on current frame and than e.g. scale them to zero so both handles had a same position. It allows you to get correct motion without any weird pops or something

But if you enable that and only select the main point, not the handles, and try to move it, you get an issue where one handle is stuck.

oh, didn't know that, with include handles it works fine for me. What is parent Graph point?

You need to alter the keymap. There is an option in the box select operator to detect handles or not. It’s off by default. So that part is not a bug.

In T64303#674236, @William Reynish (billreynish) wrote:

I cannot reproduce this. I can select handles when I set the keymap option to include handles.

Here is a GIF -

I cannot reproduce this. I can select handles when I set the keymap option to include handles.

yes, when the option is OFF you can't select single handle (or more) and when option is ON you can't deselect handles and keyframes (to keep selected only single handle)

I should note that you have to untick the "Only selected keyframe handles" option to be able to reproduce this.

• Final remarks by Campbell

Minor notes inline, otherwise fine.

• Use Operator instead of bpy.types Operator

• Make the operator work with object pinning

Since I wouldnt know how to proceed with this, stepping down...

Well, there is a common workflow in "hi-end", (Disney, Sony studios) animation. To get physically right and appeal animation you sometimes copy curves from e.g. master_control to many other bones, face bones, arm bones, e.g. from location to rotation and location, depends on specific situation. Obviously you need to copy only specific curve at once and paste it into specific curve. Previous behavior was unhandy enough, graph editor was too messy because of other curves\keyframes visible.

Here keys in all 3 channels were selected, but it was not visible to the user due to "Show Selected"

Basically, if you are pasting multiple curves, Paste does some magic to match up channels by property name and coordinate axis. This allows you to safely copy & paste all transform curves at once, but if you want to copy & paste between arbitrary channels, you must ensure you only copy one curve, and paste into one channel. Here keys in all 3 channels were selected, but it was not visible to the user due to "Show Selected". The clipboard thus ended up containing all 3 curves, and Paste applied the axis matching logic.

In rBfc040335b7a5eeaa3c57bd176656f86f9d56dc48#227888, @Alexander Gavrilov (angavrilov) wrote:

When "Only Selected Curve Keyframes" is enabled, it must work like this, because otherwise it is very confusing, as shown by the bug report.

Then, the next question is whether display options should affect the behavior of operations. If not, then it has to always work like in this commit...

I didn't get. what the problem with copy keyframes since the fix was made.. seems it copy paste as usual.. I can copy paste them in graf editor or dopeshit and it doesn't matter channel selected or not. here is a gif -

The "flattened" thing is completely misleading: it is actually copying the X and Z curves of the original bone, which contain non-zero values, likely due to numeric precision limitations in matrix operations of transform tools.

@Alexander Gavrilov (angavrilov) I agree with @Stanislav Ovcharov (Stan1) that the current behaviour is rather strange. I haven't tried this myself, but copying a nice curvy curve and seeing that the result of pasting is a almost completely flattened curve would make my scratch my head. Who would see this as desirable behaviour?

In T63980#669359, @Alexander Gavrilov (angavrilov) wrote:

Selecting channels doesn't matter for Copy, only selecting keyframes themselves. View -> Only Selected Curve Keyframes makes this confusing, but it's off by default. Maybe when that option is enabled, Copy should also only use selected curves.

Changing this is a one-line fix, but I'm not sure nobody would complain if it were changed to be the other way. As I said, this is completely a UI design issue.

Selecting channels doesn't matter for Copy, only selecting keyframes themselves. View -> Only Selected Curve Keyframes makes this confusing, but it's off by default. Maybe when that option is enabled, Copy should also only use selected curves.

In T63980#669353, @Alexander Gavrilov (angavrilov) wrote:

Your file has keyframes in all three curves selected (check Dope Sheet), so Copy stores all three curves, and subsequently Paste selects keys from the appropriate X, Y or Z curve. If you deselect all with A and then select only the Y curve before Copy, everything works as you'd expect. I.e. to paste from arbitrary curve to arbitrary curve, you must ensure that only one curve is selected both during Copy and Paste.

Possibly you could argue that Copy should take into account which curves are selected in the Graph editor (like Paste does), instead of just keyframes, but this is a UI design issue, not a bug as such.

Your file has keyframes in all three curves selected, so Copy stores all three curves, and subsequently Paste selects keys from the appropriate X, Y or Z curve. If you deselect all with A and then select only the Y curve before Copy, everything works as you'd expect. I.e. to paste from arbitrary curve to arbitrary curve, you must ensure that only one curve is selected both during Copy and Paste.

I would set that to high priority bug at least among animation tasks, because this is a fundamental workflow in graph editor

• Merge branch 'master' into temp-sybren-disable-constraint
• Use getattr(…, …, None) to prevent AttributeError

Asserts for me: