Krita 5.0 & animation docker

[Grum999]

Hi

I know that Krita 5.0.0 is still in prealpha and 2 developpers are working on this part.
But I already have some feedback concerning changes made on animation timeline docker.

Maybe these point are already fixed on developper’s side, or not…

Here interface in Krita 5.0

Some interface elements have been moved in docker title bar; this is a good idea to improve UI space

But there’s some problem to use it…

---

(1) Speed spin editor height is very small…

Maybe it should be possible to reduce/remove top&bottom margin…
(like for frame register)

Or better to move it to move to animation settings menu (with “drop keyframe” option)
Because it take space in UI and sincerely, I’m not sure that speed play is frequently modified by users (Personally I never use it, I prefer to change framerate is needed)

---

(2) Oignon and menu are far-far away than other buttons…

I’m not sure that a good thing, and as they’re positioned against the docker default buttons I found they’re hard to see

---

(3) In krita 4.x there’s more navigation buttons

Are now missing:

• First keyframe
• Previous keyframe
• Next keyframe
• Last keyframe
  

These buttons are very important: when you have multiple layers with hundred/thousand of frames/key frames, they allow to navigate/jump very quickly to next important keyframe without having to scroll and click to check if keyframe is the right one.

Is it possible to see these button back ?

(4) Auto frame mode

Now in animation settings menu

This one is important and should be available in button bar.
Also, the group button is replaced with a button menu.
You now need to open animation settings menu (1 click) and then auto frame mode menu (2 click) just to check in which mode we are working (Krita 4.x: just take a look to interface, button icon change according to mode + button is up/down)

At least, if menu is kept to reduce number of button in interface, icon should be updated according to defined mode)

UI proposition

Animation settings menu:

Docker button bar:

Grum999

[EyeOdin]

Go to keyframe back/forward is importants

[anarquero]

Nice tread!

Just two developpers? I paid my respect for them!

I’m hyped for this update .

[tiar]

There are two developers working nearly exclusively on animation for a year now: @emmetpdx and @eoinoneill . Overall Krita has 9 paid developers right now.

And the update has more things than just animation, but - yeah, that’s a big part

[emmetpdx]

Hey Grum, I’m one of the devs who’s working on the new animation stuff.
Thanks for all of the great feedback.

(1) Speed spin editor height is very small…

Yeah this is a bug/regression introduced a few days ago when someone changed the button styling. It’ll be fixed!

(2) Oignon and menu are far-far away than other buttons…

Well, the basic idea is to present the most commonly used workflow items (the buttons that we press most often as animators) right out front while moving the set-and-forget configuration widgets into sub-menus. We could have aligned the sub-menus to the left, but I think it’s more of a clear design to put actions on the left and sub-menus on the right. Eventually we will be moving other sub-menus, like audio, over there as well so I think the design will become more clear over time.

Please give it some time to grow on you, and if it still bothers people a few versions in we can always change it.

(3) In krita 4.x there’s more navigation buttons

Yeah, that’s true. We’ve opted to remove the first keyframe and last keyframe buttons because we now have a stop button that brings us back to the first frame and there really isn’t enough practical utility in jumping to the last frame to justify the extra button. (Jumping to the last frame is still possible via hotkey actions, though.)

I’m still thinking about what we should do in regards to the previous/next keyframe buttons. It’s definitely useful, but the main issue is that we have a lot of different actions for jumping to keyframes now (like jumping to the next keyframe of the same label color, and I think jumping to the next visible onion skin key is in our todo list), so the questions are (a) which of these needs a dedicated toolbar button and (b) is there a way to support these things without cluttering the interface too much and making it harder for new users to understand.

We will work on it, but for now please bind a hotkey to the previous/next keyframe actions.

(4) Auto frame mode

Hmm, I’m not sure. Is the auto frame mode something that you change often while animating?

In my experience, I usually just set it once and then draw a whole bunch of frames, but I know that everybody has a different workflow.

(5) Speed control in settings menu

This was the case a few months back, but we were asked to move it out onto the toolbar!

I personally don’t interact with it too often while animating, but some people like to use it to preview their animation at different speeds without manually scrubbing, so we went with it.
It’ll stay on the toolbar for now until we really start running out of space.

---

Anyway, @eoinoneill and I will take all of this feedback into consideration. I really want to make a big impact when it comes to improving animation workflow in Krita 5, so I appreciate your input.

Thanks!

[Grum999]

Hi @emmetpdx

Thanks to took time to read all my remarks

I understand that’s very difficult to take in account all users point of views, desideratum and workflows habits

Here my remarks.

@emmetpdx

We could have aligned the sub-menus to the left, but I think it’s more of a clear design to put actions on the left and sub-menus on the right

I can understand the idea of a strong separation between a button-menu and actions.
I know it’s more a personal feeling than a strong argument, but with current result, there’s visually something wrong and I found very difficult to reach menu.
(note: since dots “⋮” have been replaced with hamburger " ☰ " it’s a little bit better, but not yet convinced…)

@emmetpdx

we now have a stop button that brings us back to the first frame

Ah ok… I didn’t think to click on it while not playing and was wondering why the stop button was here when not playing

I just play a little bit with it and I don’t know what to think…

• First point, for me that clearly not intuitive to click on stop to go back to first clip frame when there’s no playing.
  After, I understand the idea of pause button, let to inspect immediately this frame (but, at 24 or 30 i/s when you click on pause you’re already far from the frame(s) you want to inspect)
• Second point, behavior of stop button is not the same according to current state (play/pause/stop)
  That’s really disturbing.
• Third point, there’s no more possibility to jump to last clip frame

My point of view is the jump to first/last clip frame buttons are a better option, more intuitive.

@emmetpdx

I’m still thinking about what we should do in regards to the previous/next keyframe buttons.

Ok I understand why they’re not here anymore…

You’re talking about “jumping to same label color”
Woow!
How it’s possible, I didn’t saw it!
That’s wonderful

For me, the jumb to next/previous keyframe is mandatory.
That’s currently what is the most problematic for me.

A simple idea; keep the buttons and:

• Button click = jump to previous/next frame
• Button click + CTRL key = jump to previous/next color label
• Button click + SHIFT key = jump to first/last clip frame
• Button click + ALT key = jump to previous/next visible onion skin frame
  => A tooltip should help to inform user about possibility to use modifier keys on button

1. You keep UI with less buttons
2. No need to choose between which action don’t have to choose between

In addition, you can add amenu in current context menu:
Go to

• Next key frame
• Previous key frame
  –
• Next color label
• Previous color label
  –
• Next visible onion skin frame
• Previous visible onion skin frame
  –
• First clip frame (xx)
• Last clip frame (xx)
  –
• First (non empty) layer keyframe
• Last layer keyframe

It doesn’t pollute interface and it still accessible for guys like me who only have tablet and 6 buttons to work (I don’t use keyboard…)

@emmetpdx

Is the auto frame mode something that you change often while animating?

Yes

I think 75% time, it’s set on “Autokey blank”
But according on layer I’m working on, I have to switch between different mode.

@emmetpdx

but we were asked to move it out onto the toolbar

@emmetpdx

I will take all of this feedback into consideration

Thanks
Hope my last arguments/propositions could help

For now I will continue to use Krita 5 even if it’s not recommended to use a pre-alpha, but for what I saw it’s stable enough to be used (for my usage) and I have 2 backup files defined in settings, in case of…

Grum999

[Voronwe13]

@emmetpdx, Regarding the Stop button, I think if it’s going to do different things, it needs to change its icon to show what exactly it will do when pressed. Using the Stop button to go to the first frame is not intuitive behavior. It would be much better to have redundant controls than to rely on unintuitive behavior to keep functionality.

I definitely agree with @Grum999 (and was going to suggest this myself) that a really good option for the previous/next buttons is to use the CTRL/SHIFT/ALT modifiers to switch between how the next/previous buttons switch frames, if we’re losing the explicit buttons we had for those things. Making people create shortcut keys for things they used to have UI buttons for is not a good solution…

[emmetpdx]

Regarding the Stop button, I think if it’s going to do different things, it needs to change its icon to show what exactly it will do when pressed. Using the Stop button to go to the first frame is not intuitive behavior. It would be much better to have redundant controls than to rely on unintuitive behavior to keep functionality.

Fair enough. I don’t think the difference in behavior justifies a separate button, but I think changing the icon is a good idea.

(The main thing I want to avoid is having individual buttons for all of the different possible actions, because (a) they aren’t all fundamental and (b) it won’t take long before the timeline starts to look like an airplane cockpit, as we have a lot of different ways to manipulate the timeline.)

I definitely agree with @Grum999 (and was going to suggest this myself) that a really good option for the previous/next buttons is to use the CTRL/SHIFT/ALT modifiers to switch between how the next/previous buttons switch frames,

Yeah I agree, this is a good idea. Especially if we change the icons. I’ll test it out!

Making people create shortcut keys for things they used to have UI buttons for is not a good solution…

To be fair, we’re talking about the master branch here.

The new animation GUI and features are in a relatively stable and usable state right now, but are by no means finished. So when I suggest that someone uses a hotkey for now, I mean while they are testing an in-development version.

With that said, Krita has many more actions than it has buttons, so there will always be some (usually more advanced or niche) features that don’t make it onto the GUI. For example, I don’t think that it makes sense to add a button for “next keyframe of the same color label”. So, when it comes to what gets a button or whether that button ends up on the toolbar or not, it’s a matter of where we draw the line, not if. Know what I mean?

[emmetpdx]

I know it’s more a personal feeling than a strong argument, but with current result, there’s visually something wrong and I found very difficult to reach menu.
(note: since dots “⋮” have been replaced with hamburger " ☰ " it’s a little bit better, but not yet convinced…)

Ok, I’ll keep that in mind. I think Scott has been working hard, going around Krita changing some of the icons to try to unify things a bit (for example, so that all the menus use the some icon), so the look is still changing all the time.

• First point, for me that clearly not intuitive to click on stop to go back to first clip frame when there’s no playing.
  After, I understand the idea of pause button, let to inspect immediately this frame (but, at 24 or 30 i/s when you click on pause you’re already far from the frame(s) you want to inspect)
• Second point, behavior of stop button is not the same according to current state (play/pause/stop)
  That’s really disturbing

Yeah, I see what you mean.

Previously we had a pause button that didn’t act as I would expect. Generally when you pause something it stops right where it is, but our old pause button would bring you right back to where you started playing from. Not only did people want to have the ability to pause their animation and immediately add or edit a keyframe, but I also felt that the current behavior was more akin to stop.

So, we added a true play/pause button that works how I would expect, and then we added a dedicated stop button that brings you back to where your playback started from (just like the old behavior IIRC).

When it came to jumping back to the very start, Eoin and I considered re-adding the old first frame button, but we thought we could actually just reuse the stop button, since otherwise it basically does nothing if you’re already stopped. ( I’m in my early 30s now, so I remember back in the day the standard for CD players was that hitting stop once would bring you to the beginning of the current track, and hitting stop again would bring you all the way back to the start of the CD. So I didn’t find it too weird to do something similar. )

Third point, there’s no more possibility to jump to last clip frame

Personally, I don’t find myself using the jump to last keyframe button often, so I didn’t see much of a reason for it to be there other than as a companion to the jump to first keyframe button. I still wonder if it’s really needed…

You’re talking about “jumping to same label color”
Woow!

Yeah we added that one a few months ago at the suggestion of a user, and it’s pretty useful especially if you use a lot of color labels to organize your keyframes! That’s the type of thing that is more advanced so we probably will just keep it as a hotkey.

A simple idea; keep the buttons and:

Button click = jump to previous/next frame
Button click + CTRL key = jump to previous/next color label
Button click + SHIFT key = jump to first/last clip frame
Button click + ALT key = jump to previous/next visible onion skin frame
=> A tooltip should help to inform user about possibility to use modifier keys on button

You keep UI with less buttons
No need to choose between which action don’t have to choose between

Yeah, that is a good idea and we may be able to do something like that. ALT may be a no-go thought, because I think we generally try to reserve it. (Could be wrong though!)

In addition, you can add amenu in current context menu:
Go to

Great idea. I’ll add it to our TODO list.

For now I will continue to use Krita 5 even if it’s not recommended to use a pre-alpha, but for what I saw it’s stable enough to be used (for my usage) and I have 2 backup files defined in settings, in case of…

Glad to hear it. It’s nice to know that someone is testing it regularly, since i rarely have time to animate these days.

[EyeOdin]

I donno modifiers for a timeline menu seems dodgy… why not slimmer buttons instead for those modifier actions and normal sized buttons for the main functions?

[Grum999]

Hi

@emmetpdx

I think Scott has been working hard, going around Krita changing some of the icons to try to unify things a bit

Yes I know, I’m following the topic

@emmetpdx

I’m in my early 30s now, so I remember back in the day the standard for CD players was that hitting stop once would bring you to the beginning of the current track, and hitting stop again would bring you all the way back to the start of the CD. So I didn’t find it too weird to do something similar

Yes I remember this too

But I currently feel very uncomfortable to use it…
I don’t know if there’s many people using Krita 5.0.0 for testing
Maybe I’m the only one feeling uncomfortable with new interface

@emmetpdx

Yeah, that is a good idea and we may be able to do something like that. ALT may be a no-go thought, because I think we generally try to reserve it. (Could be wrong though!)

For ALT it was just an idea.
But you can notice that some tools (like selection tools) use ALT key as tool modifier

Finally on my side, I only want a way to be able to jump to some important keyframe like before and if you can implement key modifiers and/or context menu I’ll be happy with it

Grum999

[z01ks]

I’d like to make two requests.

1. Automatic Begin and End time adjustment for the playback, so the user would not have to enter the numbers every time.

2. Display the waveform - this is essential for doing lip sync.

[z01ks]

Would it be possible to create an additional tiny docker for scrubbing the timeline? This would be an improvement since right now the user has the option of either using hotkeys for next/previous frame/keyframe or scrubbing along top portion of the timeline, where the frame numbers are displayed. This timeline bar however is usually docked way at the bottom of the screen and it’s quite a small area so the user has to be pretty precise, in addition to moving their hand a fair distance from the drawing to do the scrubbing motion.

I think it would be awesome to have this small draggable docker that the user could put next to their drawing and use for scrubbing the timeline back and forth. This docker wouldn’t have to contain the whole timeline, it would be just a button and when the user presses and holds on it, they could drag to the left and right. It could be something similar to the Puck in Autodesk Sketchbook.

Also it would be nice to have the option of kinetic scrolling for the timeline.

[EyeOdin]

You can scrubb the strip is just too thin to hit on consistently maybe just make that a bit thicker instead of a cloned docker.

How does one tablet kinetic scroll?

[z01ks]

Kinetic scroll is already available and afaik this is what happens when you use the middle mouse button and drag left or right anywhere in the timeline or up and down in the layers docker, if you have a ton of layers… It can be enabled in Config - General - Tools. This is kinetic scrolling right? I just meant this could be used for playback scrubbing back and forth, with this little additional docker. You would only need one button, and dragging left and right on it will play forwards and reverse at different speeds using this kinetic mode… Or even without it, just moving the mouse left and right faster or slower. I think being able to do this often is essential for improving your animation, as traditional animators used to flip back and forth between pages A LOT. Well that’s possible with hotkeys I know, but something about scrubbing feels more natural.

Btw I’m not sure if kinetic scroll is available for panning the canvas?

[EyeOdin]

But if your animating your on a tablet and not using the mouse so you probably don’t have access to the middle mouse button. At least in most cases. I don’t unless I swap out into the 3d pen.

Also scrubbing on a button sounds weird. I tend to have varying speeds and vary frames i go back and forth to get the the feel of it. I think a substitute for the time line for it is very hard. But maybe it would work better than I would expect. I donno.

[z01ks]

I just find this part of the animation work process more intuitive in something like Flip-a-Clip, the Android app. Since the timeline is right there and it can be dragged back and forth so intuitively, I end up using it more often. With PC applications the playback and scrubbing is either on hotkeys or in the dockers. The dockers are a bit far so it would be nice to have a little floating thing you can always position to a nearby area where you’re drawing, and it would be this large button and uncluttered so you wouldn’t have to worry about being too precise. This is one of those frequent actions that I’d like to have as little stress from as possible. Currently with the timeline, you have to be quite accurate every time and as I said it’s a bit far to move the stylus.

Btw I do have middle mouse on stylus, but I don’t think that’s relevant.

[emmetpdx]

@Grum999 Hey, so the other day we added the ability to turn the prev/next frame buttons into prev/next keyframe buttons by holding Ctrl (while the timeline docker has focus, so you need to click anywhere on it first.)

What do you think about this? It’s maybe a bit less obvious than added extra buttons, but I think it’s still relatively intuitive, since it’s kind of like holding ctrl to move between words in a text editor…

Also, also we’ve added an extra mini-feature that tries to estimate where you’ll want the next frame to go when you click on next keyframe at the end of your animation. It’ll look at the timing of the previous two frames and jump ahead by the same timing.

If you want to test this out please check out the Krita Next nightly build from krita.org

[Grum999]

Hi @emmetpdx

Thanks for info.

Tested, works practically perfectly

But there’s a small boring thing: as you said, the CTRL key is taken in account only if timeline docker have focus.

But the following case:

• Timeline don’t have the focus
• I press CTRL
• I click on prev/next button

=> Cursor move to Prev/Next frame (ok, not a surprise according to given information)

But in this case, I have to release CTRL key to press it again to start to be able to use it (ie: while key is pressed, button state/function won’t change)

Intuitively, when I change frame I just click directly on a button (with eventually a modifier key pressed)
I don’t think to click somewhere else (except on timeline frames otherwise ) before…

Is it possible to change this?
I mean, even if button icon isn’t changed if timeline don’t have focus, when button is pressed, it’s still possible to check modifiers at this moment and at least take it in account at this moment.

Grum999

[emmetpdx]

Yeah, that is a problem come to think about it…

I’m not sure if what you’re suggesting is possible, because QWidgets are designed to only accept keyboard events when they have focus. Keyboard Focus in Widgets | Qt Widgets 5.15.3 So when the Timeline Docker doesn’t have focus, it won’t see the event caused by pushing down the Ctrl Key.

So we’ll probably have to back away from this design.
I guess I’ll just have to add the Prev/Next Keyframe buttons.

edit: I’ve just gone ahead and added the Prev/Next Keyframe buttons to the timeline again. If we really need to save some space down the road we can come up with something else do it. Try it out in the next Krita Next nightly build, or of course if you build master from source.