Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't move time indicator on certain keyframe operations #1247

Open
2 of 3 tasks
Jose-Moreno opened this issue Aug 19, 2019 · 2 comments
Open
2 of 3 tasks

Don't move time indicator on certain keyframe operations #1247

Jose-Moreno opened this issue Aug 19, 2019 · 2 comments
Labels
Enhancement UX Related to the way users interact with the program

Comments

@Jose-Moreno
Copy link
Member

Jose-Moreno commented Aug 19, 2019

Issue Summary

This is a mighty annoying issue, when you're organizing keyframes and you delete one just to have the time indicator move back. Don't please. Let it behave the same way like when you add a keyframe, where the time indicator sticks in the same frame.

This may sound like a very odd and particular request but i've had to struggle with this when working on Pencil2D. It's one of those things that no one software does.

If we go further the time indicator should not react to the keyframes. You are always expecting it to keep showing the frame you want it to.

In the case of keyframe duplication it feels ok because it takes you to the duplicate, but it could be better by allowing you to duplicate the previous keyframe on ANY frame the time indicator is located at.

Otherwise let's not move the time indicator without user intent.

  • Keyframe creation: time indicator stays on the desired frame
  • Keyframe duplication: Change behavior so the indicator is moved first, to the frame you want the duplicate to be located at. If you press the duplicate keyframe button, it will take the previous keyframe available and duplicate that ON location. If you place the time indicator over the keyframe then it behaves like it is right now, where the keyframe spawns on an adjacent "free" frame. (Ideally I would like the split insert option to be implemented instead, so the new duplicate pushes existing keyframes, we could use the code that is used when pressing ALT and moving all the the keyframes too)
  • Keyframe deletion: Change the behavior so the time indicator it's not moved from the place the keyframe was deleted.

Edit: Due to feedback by scribblemaniac, I agree that on this last point, having the current behavior can work very well for a different use case, like when you want to promptly delete all the keyframes quickly, so could this be a toggle behavior?

Edit2: Thinking about it more calmly we could have modifiers to extend the behavior, of the keyframe manipulation operators.

The premise is that none of these should move the time indicator, but there ar euse cases where it is indeed desired that it moves. The keys is user intent.

  • Keyframe removal:
    • Normal: Timeline indicator does not move
    • Extended: Use a modifier key and then the time indicator will jump backwards or forwards towards the next keyframe to help delete it faster.

Steps to reproduce

  1. Move the time indicator to a desired frame
  2. Create a new keyframe: The time indicator stays on the chosen frame
  3. Delete the keyframe: The time indicator moves one frame back (?????)
  4. Move the time indicator to the previous keyframe
  5. Duplicate the current keyframe. the time indicator is moved to that location.
@Jose-Moreno Jose-Moreno added Enhancement UX Related to the way users interact with the program labels Aug 19, 2019
@MrStevns
Copy link
Member

If we go further the time indicator should not react to the keyframes. You are always expecting it to keep showing the frame you want it to.

This sounds a bit wrong but maybe that's just my interpretation of the above sentence. The time indicator should move to the position where you intend to create a new keyframe. We can't stay on a frame, create a new somewhere else and not expect the indicator to not move since it's tightly coupled together.

I do agree though that deleting a frame shouldn't necessary scrub back.

@Jose-Moreno
Copy link
Member Author

@candyface

The time indicator should move to the position where you intend to create a new keyframe

It's exactly as you put it . Maybe i should have phrased that differently. Apologies for any confusion.

The time indicator has to move where you want it to. So you move the indicator and then create, duplicate or delete keyframes.

So far it almost works like that, what I don't agree is there inconsistent behavior where creating a keyframe keeps the time indicator in place, but for deleting and duplicating it does not.

In the latter cases it's being proposed that:

  1. if you move the indicator and duplicate it should be similar to keyframe creation but using as a base the "previous" keyframe
  2. if you place the time indicator on top of an existing keyframe it should keep the current behavior where the keyframe is duplicated and the time indicator moves to the new keyframe (it still would seem to obey the same rules as no. 1)
  3. If you're deleting a keyframe it should not move backwards, unless you want it to (thus the proposed use of a modifier for alternate behavior)
  4. Deleting a keyframe should be possible from it's "exposure" (this would be akin to say "delete previous keyframe" if you're on an empty frame)

Some of these ideas might not be necessarily implemented now, as there might be changes with a new timeline implementation. So all i'm asking is to keep it in mind once we do get to that point.

Regarding my comment on your undo PR, it's just the toggle that I'd like to see if you're going to work on that feature anyway. But if it's not possible then we should at least make it clear that such feature will come eventually 😄

@Jose-Moreno Jose-Moreno added this to Medium Priority in Enhancement Priority Aug 31, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement UX Related to the way users interact with the program
Projects
Status: Medium Priority
Enhancement Priority
  
Medium Priority
Development

No branches or pull requests

2 participants