Krita 5.0 & animation docker

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 :slight_smile:

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
    image

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 ? :slight_smile:

(4) Auto frame mode

Now in animation settings menu
image

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:
image

Docker button bar:

Grum999

8 Likes

Go to keyframe back/forward is importants

Nice tread!

Just two developpers? I paid my respect for them! :grin:

I’m hyped for this update :laughing:.

1 Like

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 :slight_smile:

2 Likes

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

(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! :stuck_out_tongue:

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. :slight_smile:

Thanks!

2 Likes

Hi @emmetpdx

Thanks to took time to read all my remarks :slight_smile:

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

Here my remarks.

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…)

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 :sweat_smile:

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 :frowning:

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

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 :star_struck:

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 :arrow_forward:

  • 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…)

Yes :slight_smile:

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.

:dizzy_face:

Thanks :slight_smile:
Hope my last arguments/propositions could help :wink:

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… :smiley:

Grum999

2 Likes

@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…

1 Like

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?

1 Like

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. :stuck_out_tongue: )

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 :arrow_forward:

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

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… :smiley:

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

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?

Hi

Yes I know, I’m following the topic :wink:

Yes I remember this too :sweat_smile:

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 :thinking:
Maybe I’m the only one feeling uncomfortable with new interface :grimacing:

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

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 :wink:

Grum999

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.

1 Like

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.

image

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

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

How does one tablet kinetic scroll?

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?

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.

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.