Fix #105329: Keyframe handles staying in place when using slider operators #105401

Christoph Lendenfeld · 2023-03-03T13:02:40+01:00

2023-03-03 13:02:40 +01:00

The issue was that when using the HD_ALIGNED handle type,
Blender would not automatically move the keyframe handles with the key.
Instead one handle would get stuck in place.
To remedy that manually move the keyframe handles in case the type is HD_ALIGNED
This makes it consistent with moving a key with G

The issue was that when using the `HD_ALIGNED` handle type, Blender would not automatically move the keyframe handles with the key. Instead one handle would get stuck in place. To remedy that manually move the keyframe handles in case the type is `HD_ALIGNED` This makes it consistent with moving a key with G

Christoph Lendenfeld added the

Module

Animation & Rigging

label 2023-03-03 13:02:40 +01:00

Christoph Lendenfeld requested review from Sybren A. Stüvel 2023-03-03 13:02:59 +01:00

Christoph Lendenfeld changed title from ~~Fix 105329: Keyframe handles staying in place when using slider operators~~ to Fix #105329: Keyframe handles staying in place when using slider operators

2023-03-03 13:03:28 +01:00

Sybren A. Stüvel approved these changes 2023-03-03 13:07:31 +01:00

source/blender/editors/animation/keyframes_general.c

						
				@ -229,0 +230,4 @@

				{

				  const float delta = key_y_value - bezt->vec[1][1];

				  bezt->vec[1][1] = key_y_value;

				  /* When handle type is HD_ALIGN one handle would get stuck. */

Sybren A. Stüvel commented

2023-03-03 13:07:26 +01:00

"one handle would get stuck" → "handles get stuck unless we move it along with the key".

It's a bit more generic, but does avoid some questions, like "if you now which handle gets stuck, why move both?", or "why not mention which one?". I think the approach of simply updating both is the right one, so that's why I think the slightly more generic comment is better.

Also it describes the issue, instead of the history of the code.

The rest LGTM, so this can be addressed before merging the PR.

"one handle would get stuck" → "handles get stuck unless we move it along with the key". It's a bit more generic, but does avoid some questions, like "if you now which handle gets stuck, why move both?", or "why not mention which one?". I think the approach of simply updating both is the right one, so that's why I think the slightly more generic comment is better. Also it describes the issue, instead of the history of the code. The rest LGTM, so this can be addressed before merging the PR.