Allow jumping to previous/next keyframe in animation player

[passivestar]

Adds buttons hotkeys to go to previous/next keyframe

Edit: Instead of buttons this PR now only adds the functionality itself and exposes hotkeys for it. UI buttons may be added in the future, see discussion below. Leaving the video in for demonstration

If anything is selected in the scene it uses the keyframes of selected nodes. Otherwise it uses all keyframes in the current animation

keyframes.mp4

Works the same way in bezier mode, it just ignores non-bezier tracks because you can't see them in the bezier editor

Shift+Alt+A - Previous keyframe
Shift+Alt+D - Next keyframe

Note: Animation editor is using hardcoded shortcuts for all buttons, it would be nice to make them rebindable in a future PR - (Edit: Done)

Note 2: When no keyframe to the left/right exist it jumps to the beginning or the end of the animation. Although those aren't keyframes I think this behaviour can be useful because we don't have dedicated buttons for that

Note 3: I left the repeating code in the loops because moving it into a new function would be a bit awkward since it needs to modify the nearest_key_time and it would hurt readability, but let me know if you think I should do it anyway

Closes godotengine/godot-proposals#10142

[fire]

I did not review the code yet, but I like the feature proposal.

[Mickeon]

Not against this in the slightest but I'm severely concerned about the sheer amount of play buttons present. 5 is already many as is and... somewhat hard to distinguish in their current state.

Main issue is that the current icons are not as distinct as Blender's, so I would be wary of that first.

[passivestar]

Not against this in the slightest but I'm severely concerned about the sheer amount of play buttons present. 5 is already many as is and... somewhat hard to distinguish in their current state.

Personally I'd remove the "play from beginning/end" buttons and expose their functionality through Shift+Click on the regular play buttons + keep their hotkeys (Shift+A/D). I find it especially unlikely that "play backwards from end" is used often to justify a button for it. You can also click on the stop button when the animation is not playing to jump to the beginning. That's already 3 different ways to play from the beginning without a button for it

Main issue is that the current icons are not as distinct as Blender's, so I would be wary of that first.

I want to tweak them a little to make them consist of two visually distinct elements instead of one shape for better clarity. Like in blender

[Mickeon]

By all means, those sound good to me. Never liked the design of anything Animation-related, so it may be a step in the right direction.

[passivestar]

By all means, those sound good to me. Never liked the design of anything Animation-related, so it may be a step in the right direction

I will tweak the icons in this PR, but open a separate one for additional cleanup because if we decide that those extra buttons should go I'll also need to make their hotkeys rebindable as I mentioned in the note above. I might also experiment with a design where play buttons are combined with the stop button

[TokageItLab]

Not against this in the slightest but I'm severely concerned about the sheer amount of play buttons present. 5 is already many as is and... somewhat hard to distinguish in their current state.

I agree with @Mickeon. Although I can agree only with the addition of pull-down menus (or right-click menus) and the addition of shortcuts, but I do not agree with the addition of buttons.

There are other methods to move the timeline cursor besides keyframes, such as moving to the snap position, but it is not made a button. Also, since we are planning to add markers in #91765, there is a possibility of moving to markers, but I don't think that all of them should be made into buttons for moving the timeline cursor in the same line with playback button. So I do not think that keyframes should be treated specially.

The play button should only be for the playback (play() or stop()) API, and if you want to add a button for movement, I believe it should be on a separate line or Somewhere completely recognizable as different from the playback API, like:

Personally, I think this PR can be approvable if the buttons are removed.

[passivestar]

@TokageItLab Thanks for the feedback! I'm ok with it being shortcut-only for the time being!

I removed the buttons and exposed the shortcuts. We can get this in and then decide on the best UI once the animation editor is feature-complete, including markers and whatever else it may need

Since the hardcoded hotkeys needed to be removed from buttons' tooltips I also made the tooltips match the text of the shortcuts for less needed translations and removed the words "selected" and "current pos" which are arguably redundant in context

[TokageItLab]

I think it works well.

However, I think it is weird that the tooltip description for playback from the end is exactly the same for backward and forward playback, so I think some different wording is needed. Any one of the three suggestions below would be sufficient. If you have any other good ideas, feel free to suggest it.

[akien-mga]

Thanks!

[tutabot]

I really love the feature, but removing the UI buttons is a really terrible choice.
Shortcuts are for pro users who use a feature every day. There should always be an easily discoverable option to use a features for people who do not use it every day. A feature which is only available through Shortcuts has the worst discoverability.

I strongly disagree with TokageItLab and Mickeon. The UI Buttons presented by passivestar are clear and easily understandable. I find the play button UI suggestion by TokageItLab much harder to grasp.

[Mickeon]

I want the UI buttons, too. Delegating this feature to a secret option is the worst option, but it's worth addressing the current UI in separate PRs, such that it is not too overwhelming for most users but still very much accessible.

[nuclear]

+1 for the keyframe buttons! This is a button the average user will want to use.
The play / play from start button should be merged. Play with a regular click, play from start with a shiftclick.

[TokageItLab]

I have no strong insistence on the UI I have suggested above. However, we need to avoid confusing the "editor controls" with the "play/stop API which also available at runtime". So I would never agree to add it in the same line as the playback button.

Based on experience with AfterEffects, adding a keyframe move button next to TrackName in TrackEditor might be appropriate in terms of positioning in terms of functionality, although it may require a new implementation of moving to keyframes individual track. How about it?

Also, there are several cases where keyframe jumps for all tracks will be useless when editing an animation with a large number of keyframes, such as copy of the externally imported 3D animation, or baked tween or cubic interpolation. So handling keyframe-to-keyframe jumps per track helps to handle them correctly.

[nuclear]

Yes, this sounds like the best solution!