Godot: AnimationPlayer: Timeline cursor should jump to wherever I leftclick in the track

[golddotasksquestions]

Godot version:
3.1

Issue description:
The AnimationPlayer currently only updates the 2D view when the user clicks on the timeline and therefore moves timeline cursor/timestamp (https://github.com/godotengine/godot/issues/27277)
If the user wants to insert a keyframe, they should be able to do so not by first clicking on the timeline, but directly on the location within the track where they want to insert or paste (https://github.com/godotengine/godot/issues/27280#) a keyframe. For my understanding for this to work, the timeline cursor/timestamp should jump to wherever the user leftclicks in the track. This would also allow the user to immediately see the state of the animation the user wants to change at this location. Right now, if they want to see what state the animation is at a given location on a track, the user always has to go up to the timeline and find the time, then go back down to the track. This is especially tedious the more tracks the animation has.

[KoBeWi]

Right now, if they want to see what state the animation is at a given location on a track, the user always has to go up to the timeline and find the time, then go back down to the track.

The timeline is always on the top of the Animation tab, no matter how many tracks you scroll down. Not sure what problem you are describing.

[golddotasksquestions]

I was describing the process of inserting a keyframe at a specific position on the track.
in 3.1 if you LMB click anywhere on the track, the timestamp does not jump there automatically, hence the 2D view also does not show you where you would insert a keyframe.
Even though you can add a keyframe with RMB click anywhere on the track, you have to do it blindly, or go up first to the timeline, drag or click at the time you think you want to insert a keyframe and then do the add keyframe business.

[golddotasksquestions]

What also does not work, is that the timestamp imho should jump to the position of the mouseclick when LMB clicking on a keyframe anywhere on the track. (which imho should in consequence also actualize the 2D view)
Thanks for showing an interest btw! The issue described here is bigger when there are a lot of tracks, and Godot is forcing one specific workflow onto the user.

[KoBeWi]

So again XD

Not sure why moving the timeline instead of clicking track is problematic. You can scroll to the track and drag the timeline while still seeing the track. Then you can right-click at line position.

Anyways, the enhancement you talk about is probably almost one-liner. Matter of copy-paste-change RMB behavior.

[golddotasksquestions]

Not sure why moving the timeline instead of clicking track is problematic.

It seems like a pointless additional step. Something an animator has to repeatedly do a million times a day. If you have lots of tracks that can mean you have to move around the screen a lot. Going back and forth.

Anyways, the enhancement you talk about is probably almost one-liner. Matter of copy-paste-change RMB behavior.

This is also about the LMB behaviour though. If you LMB click on the track (or on a keyframe), the timeline should jump there, no?

[KoBeWi]

I mean, if someone wants to work on this issue, they already have the RMB code, which needs to be duplicated and changed to LMB and mirror the timeline call. I was just giving hints for juniors xd

[Calinou]

Remember that when you move the timeline, it applies property changes to the currently-running scene, which can leave it in an undesired state if you save it. Until this is changed, I'm not sure if this behavior is wanted as it could end up hindering your productivity.

Also, remember that you can click and hold the mouse button to select several keyframes using box selection. Dragging the timeline when clicking on an empty space would conflict with this behavior.

[golddotasksquestions]

Remember that when you move the timeline, it applies property changes to the currently-running scene, which can leave it in an undesired state if you save it. Until this is changed, I'm not sure if this behavior is wanted as it could end up hindering your productivity.

Why do you want this changed? In my opinion this is exactly what should happen to avoid confusion.
I find it extremely irritating to have multiple different animation "states" in addition to my game states.
Whatever is visible in the editor should be the current state and applied value, imho.
The only exception is if you have a keyframe applied. Whenever you go to that keyframe, this state should become the current state of the editor. Otherwise it gets even more confusing: You get a keyed state, an editor state, a timeline state, and a run state, of your animation - all get displayed in the viewport with no indication what it is I am looking at.
Even if there was, knowing whatever I see in the viewport is the applied state of the Editor far less explaining.

[Sl3dge78]

Here's a quick fix. As Calinou said, can't really implement LMB to move the timeline as it would conflict with drag selecting.
If you have any other ideas, i'd be happy to amend.

Hopefully the PR is fine (it's my first one ever!)

[noidexe]

Here's a quick fix. As Calinou said, can't really implement LMB to move the timeline as it would conflict with drag selecting.
If you have any other ideas, i'd be happy to amend.

What about using a modifier key? For example, you hold alt and you can click and drag anywhere to move the timeline. Without alt it works as it always did and there is zero risk of people complaining that it broke their workflow somehow and asking for a toggle to disable it.

[Calinou]

Alt is a risky modifier to use, as it won't work on most Linux window managers out of the box. We'd prefer using Ctrl or Shift (or both) if these aren't used already.

(Godot already uses Alt modifiers in a handful of places, but it's considered a last resort.)

[noidexe]

Ahh yeah, I had forgotten about it since setting drag to meta-click is the first thing I do on linux since it interferes with so many apps.

Ctrl is sorta taken. If you click and drag a keyframe ctrl temporarily disables any sort of snapping. I think there is a chance of accidentally moving a keyframe just slightly when you just wanted to jump to that position. I think shift is available though

[Sl3dge78]

I looked at how other software handle this:

• Maya - Main View : Move playhead when clicking at the bottom of the main view ; Can't move keys.
• Maya - Graph Editor : Move playhead when clicking on the timeline ; Move keys by clicking on them.
• Blender : Main View & Graph Editor : Move playhead when clicking on the timeline ; Move keys by clicking on them.
• Unity : Move playhead when clicking on the timeline ; Move keys by clicking on them.
• Motionbuilder - Main View & Graph Editor (A weird one imo): Move playhead by dragging it or Ctrl + Shift Clicking ; Move keys by dragging them
  In all of these, selecting a key doesn't move the timeline to the key's position.

So the most common behaviour seems to be the original one (before my PR). I'm not even sure we need to change it anymore but I'll follow the majority. I agree with the fact that a quick shortcut to move the playhead would be nice. But there must be a reason why all big animation software don't do it.

[noidexe]

Well it's a small change but maybe this should be a proposal since it's not really something that was supposed to happen and it's not happening (a bug) but rather some desired changed in how the software should work. I don't know how many animators are following bug reports here.

I come from an animation background and I totally understand any complains about godots animation UI/UX. The animation "system" is the most powerful I've ever seen, but the UX is probably the worst, even though it improved a lot in recent versions. Animation involves a lot of repetitive inputs and a clunky UI can easily become tiring and take you out of the zone. I think this is the area that will benefit the most if a full-time UX dev gets hired, as it was mentioned in the news about budget planning.

[KoBeWi]

Well it's a small change but maybe this should be a proposal since it's not really something that was supposed to happen and it's not happening (a bug) but rather some desired changed in how the software should work.

Now that you say it, this spawned enough discussion that it should be probably moved to the proposals repo, because there's no clear consensus.