About animation related dockers

My original post in reddit
Hi! I use Krita for pixel art and have some question/suggestion.
Right now my animation-related part of the screen looks like this
It’s kind of big part of my screen. Because of the Animation docker and minimum height scale of it. I suggest to combine timeline and animation dockers in one because they are almost always used together… Something like this:


Of course, I understand that perhaps not everyone will find this change convenient. But I saw several forum posts from other people who reported a similar problem with the animation and onion skin dockers. This especially concerns people with low-resolution monitors.
Therefore, I suggest developers to consider this option of combining. I almost did not have to resize the buttons in the picture by the way.

Thank you, I hope this post did not look annoyingly displeased. Looking forward for future updates.

9 Likes

Great suggestion! I would much prefer this! I often animate on a 12 inch and a 13 inch screen, and I think the Animation docker is a bit of a hassle as it either removes a lot of my timeline width or makes my side dockers too wide!

1 Like

That’s a good idea and a neat and tidy arrangement. I notice that you have what I think are the most used icons on the left which is also good (personal opinions may vary).
My suggestion would be to have an additional docker called AnimTimeline so that people could choose to use it or not as they prefer.
If it seems to get support and agreement, you could make a Wishlist bug report which will join the queue along with other wishlist reports and fault reports. If you’re lucky, there may be a developer out there who’s itching to try something like this.

1 Like

Great suggestion to make the timeline more cohesive and less big!

1 Like

This is a nice suggestion. One suggestion would be to make the current Animation docker to be able to squeeze and reduce height so that it becomes like you suggest. That way people can stack it horizontally above timeline docker when required. and those who don’t can stack it like it is now

2 Likes

I’m all for the change too, it would be nice as the @raghukamath suggested if the docker was responsive.

There seems to be quite a bit of work done on some major resource rework and bug fixing if I remember correctly so not sure if this could get picked anytime soon but isn’t this possible with python and custom plugin? I think you can create a docker and use same functions as tools already in Krita but I’m not sure how far the python scripting goes but if possible maybe there would be someone from plugin community who would be also interested in this?

1 Like

yeah…there is a bunch of dockers that annoy me just like that one

1 Like

Something along these lines hopefully coming soon™ in Krita 5.0. =]

4 Likes

Beautiful!

1 Like

looks amazing, I just love it!

1 Like

Here is my personal lay out I’m using at this time. I like your suggestions.

Hey again @TasukeFujita and everybody else in this thread.

I just wanted to let you all know that some big changes to Krita’s animation tools have arrived in master, and are also now available for testing in the “Krita Next” nightly builds. https://krita.org/en/download/krita-desktop/

While we have to work to make a consensus and @eoinoneill and I have some of our own opinions about the direction of Krita’s animation UI, we also took a lot of inspiration from this thread and I hope that the latest design is something that you all like to use. Of course, nothing is final, so please try out the new animation tools and let us know what you think! (Sorry, no documentation just yet. If you have any questions about the changes let me know and I’ll try to answer them.)

I also want to take a minute to thank everybody for their contributions. As a community-driven and open source project Krita really benefits when people get involved and take time out of their busy lives, not only to code patches, but also making suggestions, testing, creating documentation, etc. =]

edit: We’ve also made changes to the default Animation workspace. I know workspaces are very much a matter of preference, but let me know what you think!

4 Likes

I need to find some time to properly test the new animation tools. However, by judging the screenshot, great work! I really like the way everything is positioned in the workspace. Of course there will be some personal adjustments, but that depends of each user specific workflow.

I always had some trouble positioning the onion skin docker, now fits very nice!

By the way, are the guides with the safe zones included too, or is it a layer?

Thanks for all the hard work! All those improvements in the animation are very welcome and will make Krita even more powerful!

2 Likes

It’s a layer. You can probably find it in templates, and if not, you can create your own templates. (Templates are available in File -> New dialog on the left).

1 Like

Are you sure you changed it properly? For me the Animation workspace just means everything it was before but without the animation-related dockers, because they no longer exist.

I just had a look at the Jun 25 5.0.0 prealpha appimage and it does look nice and neat and compact.
The default Animation workspace has nothing related to animation, presumably because the old ‘Timeline’ and ‘Animation’ dockers have been removed.
I’m sure this will be tidied up.

I would have liked the old dockers to be available as ‘Old Timeline’ and ‘Old Animation’ because sometimes I do like nice big buttons all grouped together for easy access.
I realise this may have been a policy decision to throw out the old and possibly to avoid confusing new users.

There are some things about it that puzzle me, as follows:

  1. Why has the Auto Frame Mode on/off icon been tucked away in the ‘Animation settings menu’ drop down, so that it needs two clicks to operate it?
    There is room for it closer to the other icons that it used to be grouped with.

  2. The Onion Skin icon has a tool tip that says ‘Audio menu’.
    I assume this is a simple error.

  3. If you arrange the Onion Skin docker at the right side of the Animation Timeline, then when you activate it the Onion Skin on/off icon jumps to the left; a bit of visual disruption.
    The Onion Skin icon could be placed at the left so that it’s closer to the layer onion skin lightbulb icons so forming a closer and natural association.

  4. The First Frame and Last Frame buttons have been removed even though there is room for them.
    The Last Frame button was useful in that it would jump to the End frame number as set in the Animation docker.
    The First Frame button would jump to the previously selected active frame which I didn’t think was much use and I’d have preferred it to jump to the Start frame number.
    That way, you could use Start and End to define a working range of interest, play it and move around in it and jump to the start and end of it.
    Notice the mismatch between ‘First Frame’ and ‘Start’ and between ‘Last Frame’ and ‘End’. I think that could be cleaned up to be ‘Start Frame’ and 'End Frame which would jump to the Start number and the End number.

1 Like

@tiar and @AhabGreybeard : Hmmm. The workspace issue is probably due to the fact that you already have the old Animation workspace in your Krita configuration directory. I pushed the new workspace to master, but it’s probably not replacing, and still loading, the old workspace. This is my first time tweaking any of the workspaces or other static resources that Krita includes, so I’ve probably overlooked something.

I would have liked the old dockers to be available as ‘Old Timeline’ and ‘Old Animation’ because sometimes I do like nice big buttons all grouped together for easy access.
I realise this may have been a policy decision to throw out the old and possibly to avoid confusing new users.

Truth be told, I’m not interested in doing this and I don’t really see it happening any time soon. Of course, Krita is an open source project and I’m not in a position to dictate anything, nor do I want to be, so if someone wants to bring back the old stuff it’s certainly possible–with the caveat that some code would need to be changed for it to work with other changes that we’ve made under the hood.

Objectively speaking, the old design was not only very space-inefficient, but it was also faux modular, in the sense that the classic Animation and Timeline dockers were so strongly coupled and codependent that there was essentially no scenario in which one of those pieces could be used without the other. If two things are always needed for a single task and can’t be used independently in any meaningful way, they are effectively one thing. Right? That’s my thought on it at least.

Why has the Auto Frame Mode on/off icon been tucked away in the ‘Animation settings menu’ drop down, so that it needs two clicks to operate it?
There is room for it closer to the other icons that it used to be grouped with.

The overall strategy here is to put the widgets that are central to the animation workflow (stuff that is used or tweaked a lot during the course of animating) front and center, while taking the set-and-forget, configuration kinds of things and place them in a little cupboard. Why?

For a few reasons. The first and biggest one being clarity. In my opinion, the more UI chrome is on the screen at once the more cluttered, confusing and potentially overwhelming the program becomes, especially for inexperienced users. Ideally, any user, even someone who is brand new to Krita, should be able to look at the Timeline and understand it in a glance. Of course experience users will just get used to anything, but I hope that even they can benefit from a Timeline that shows what they want to see more immediately.

The second (arguably less important) reason for hiding some low-traffic widgets in a submenu is that UI space is a resource. Yes, there is a lot of room on the Timeline’s titlebar right now but Krita is by no means finished, and as we continue to add features to the animation system Eoin and I both felt that some space should be reserved for potential new, high-traffic widgets.

With all that said, I think there’s definitely still room to debate which UI elements should be out front and which should be hidden. AutoKey seems to me like the type of thing that you only change occasionally, so we hid it… But I don’t know how every animator works!

The Onion Skin icon has a tool tip that says ‘Audio menu’.
I assume this is a simple error.

Yeah. That’s a bug. Nice catch! I’ll fix it on Monday. :wink:

If you arrange the Onion Skin docker at the right side of the Animation Timeline, then when you activate it the Onion Skin on/off icon jumps to the left; a bit of visual disruption.
The Onion Skin icon could be placed at the left so that it’s closer to the layer onion skin lightbulb icons so forming a closer and natural association.

Yeah. But if you were to place the Onion Skins Docker on the right of the timeline then just about everything would jump, no? I’d prefer to keep all of submenus (Onion Skins, Settings, and eventually a newly designed Audio Menu) near each other, and the right feels like a better place to do that than the left.

Maybe we can play with some alternate arrangements though. I’ve heard some people suggest having the transport controls in the middle of the titlebar like Blender does.

The Last Frame button was useful in that it would jump to the End frame number as set in the Animation docker.

I don’t see the utility in this, so we removed it. We could remake the action for it so that it could be bound to a hotkey still, but it doesn’t seem useful enough to dedicate a button to. Do you use this button often?

The First Frame button would jump to the previously selected active frame which I didn’t think was much use and I’d have preferred it to jump to the Start frame number.

The secret of the new Timeline transport controls is that the stop button has 2 behaviors:

  • Clicking stop once brings you back to the select frame (where you started playing from).
  • Clicking stop again (or anytime the active frame is the selected frame) brings you back to the starting frame of your animation.

In other words, click once for the old way, and click twice to bring you back to the first frame. Of course, none of this is documented yet and maybe we can can illustrate it better.


Anyway, I appreciate the feedback. I hope I don’t come across as defensive, I’m not trying to be, I just want to help explain some of the rationale behind various design decisions. More information can be found https://phabricator.kde.org/T12983 and https://invent.kde.org/graphics/krita/-/merge_requests/317.

1 Like

Hey thanks! :smiley:

By the way, are the guides with the safe zones included too, or is it a layer?

Like @tiar said, that’s actually just one of Krita’s default templates, it’s called the “Japanese Animator Template” or something along those lines. It’s pretty nice, if a bit over designed with multiple pre-configured layers of keys and sketches and stuff. Maybe I’ll make a simpler version.

1 Like

Not at all. You’re explaining and explaining it well, which is always good. Your rationale is reasonable (and rational). Whatever you do, there will always be someone who disagrees with some things and questions your decisions, so here I am :slight_smile:

It works and looks fine with a fresh install so yes, you have the problem of what do do with existing workspaces in the resources. Good luck with that.

I realise that the old Animation/Timeline dockers really had to be used together and were not space-efficient.
The thing with me is that I like to see everything, even if it leads to what many would regard as clutter, which I’m capable of ignoring.

As for for Auto Frame Mode, I only use it for ‘organic growth’ types of animation and the problem with set-and-forget mode buttons is that you can easily forget them if they’re not on show. If that happened then I’d quickly realise then go to change it, not a showstopper.
The Drop Frames button is always on show but I never use it so it’s different strokes for different folks.

**Little bug: The tool tip for the Auto Frame Mode doesn’t show its on/off state.

The Onion Skins docker actually is at the right side of the Timeline with the fresh installation Animation workspace. It’s only that icon and the Animation settings menu icon that jump. I only use that docker to check/set the onion skins and it hardly gets used at all so not a big deal.

Looking at it more closely, the behaviour of the (old Animation) Last Frame button is variable depending on layer content and play history (i.e if it’s ever been played or not so that may be an animation cache thing). In that case, I’m not surprised that you got rid of it but it would be nice/useful (in my opinion) to have those button that behave as I described.

As you say, the second click on Stop takes you to the Clip Start frame number so that’s good. All I need now is a button that goes to the Clip End frame number :slight_smile: I find that I’m itching and aching to see those two numbers visible and adjustable all the time but that may be just me.

I notice that you’ve fixed a long standing ‘over run’ flaw in the zoom control that happened at the max zoomed-out level and you’ve also put a sensible limit on the max zoomed-in level. I never got around to reporting those so thank you for fixing them.
** However, you now have an over-run (under-run ?) flaw at the max zoomed-in level.

If I notice anything else like that, would you prefer to be informed in a post here or should I put in a formal bug report?

1 Like

As for for Auto Frame Mode, I only use it for ‘organic growth’ types of animation and the problem with set-and-forget mode buttons is that you can easily forget them if they’re not on show. If that happened then I’d quickly realise then go to change it, not a showstopper.

That makes sense to me. I’ll try to consider that more. =]

The Drop Frames button is always on show but I never use it so it’s different strokes for different folks.

Very true. This was also a button I considered hiding, but because it lights up red whenever frames are being dropped it’s important to be able to see it, even if it’s not one that we hit very often.

The tool tip for the Auto Frame Mode doesn’t show its on/off state.

Ok, thanks. I’ll fix that one on Monday, too.

All I need now is a button that goes to the Clip End frame number :slight_smile: I find that I’m itching and aching to see those two numbers visible and adjustable all the time but that may be just me.

I’ll make an action for it, at the very least. :stuck_out_tongue:

However, you now have an over-run (under-run ?) flaw at the max zoomed-in level.

Can you elaborate on this? I’m not sure I know what you mean exactly.

If I notice anything else like that, would you prefer to be informed in a post here or should I put in a formal bug report?

Whatever is easier for you is fine with me. You can tag me here, jump into our phabricator task, find my on #krita or even write me an email. I check all of these things with kind of random frequency, lol.

I appreciate the feedback, @AhabGreybeard!