I will take a look at this and try to get started on it. If I can get in a good position for this development, I'll claim it and take the mantle. Just need time to get set up, review the Curves docker and break down the task into steps for improvement.

@kaoninjaratzu Great!

The first step I'd do is to try adding a blank KisUtilityTitlebar to the Animation Curves Docker.
If you study the code in the /plugins/dockers/animation/timeline_docker.h and plugins/dockers/animation/timeline_docker.cpp, you'll see how we did did that with the timeline.

Once you've got that you can start adding widgets to it and hook them up to the appropriate actions and slots, and that'll be a good portion of subtask 1 done.

As always, let me know if you need any help or advice.

Sounds good! Yes I will review that area to see how the working example works and apply it to the Curves Docker. Thanks for the tip! I'll start pulling the code soon and get to it!

I've added a mock-up of roughly what the finished Animation Curves docker should look like. :)

Ah excellent! Thanks for the mockup! It gives me an idea of what changes to aim for. Yeah, reducing the size of the UI icons definitely helps for smaller screens so the icons don't take too much space. I'll play with it to see if I can get it out of the way enough, but still visible for high res monitors that are physically small.

Having played a bit today, it'd be great if...

• The toggles for the visibility curve elements would be bigger and easier to click. (It seems that this was the original intention)
• The ability to alt+click on a curve in the sidebar(or just a curve itself) to only show that one, much like we have isolation mode in the layers docker. I found myself wanting to fine-tune the different parameters, and toggling 9 values gets tired quick, especially as the docker is a little vague about multi-property editing (it seems possible, happens with scale at the least but... I can't find a logic in there...)
• For the curves, it'd be super cool if we could get some stuff in from vector editing.
  • In vector editing, when I make a shape with the polygon tool, and switch to the edit-shapes tool, I can hover over a curve segment and drag it into shape, if I need a straight section, I can go to the tool options docker and select 'segment to line'.
  • Right now in the curves docker I need to jump through all sorts of hoops to make sure that a segment is curved or not.
  • Because vectors much like these curves do have an internal understanding of the difference between straight line and bezier curve, I propose that we try to hide the distinction between the two in the curves like we do for the vectors. The animator will then have to only worry about whether a section uses discrete(aka, no) interpolation or any kind of interpolation at all.
• Similarly, it'd be great if there was number input for editing parts of the curve. Animation at times is planned out math, so for a certain type of animator, being able to just input values would be great.
• There's curve presets in the brush settings curves. I think we can reuse half of them as presets somewhere(I suspect in a rightclick menu).
• Some values, like rotation degrees are traditionally circular. Can we do something here (like also having a clock/counterclock thing for rotation interpolation), or is it expected by the animator to manually have to go to 0 manually whenever then need rotation over 360?
• I see that Rotation is in radians, much like how opacity is in quint8. We should proly have user-friendly formats of these values.
• There's something to be said for maybe instead of zooming in/out having normalized representations of the curves, so they always fit inside the window? The animator will then not be able to change the values in the curves docker directly and trying to see the proportional difference of a given movement is hard, but it might be useful when fine-tuning a transition. Thinking it through, it probably would need to be a mode.
• Scalar keyframes don't seem to support (visualizing) frame labels yet. I think this would still be useful for them, as it could help distinguish between the extremes that govern the animation and the accents that add the necessary oomph to a polished animation.

A bunch of these are kinda... very large, but there's low-hanging fruit in there as well.

EDIT: I mean, having played with the animated transform masks and the old curves docker. I think that isn't very clear otherwise if reading back from the future.

I'll do my best to implement as many of these as possible.

• Bigger Toggles = Should be a matter of adjusting the pixel size for the UI. I'll definitely make sure of that as UI is my specialty
• Alt + Click to only show that one = I'll have to try it myself, but I agree, I can add that ability and make it toggle the single select.
• Curves as Vectors = I'll have to see how the vectors and curves are drawn and manipulated, but I do agree it'd be a lot easier if they used the same editing mechanism.
• Numerical input = Agree and should be easy to do.
• Curve Presets = Similar as the Curves as vectors, I'll have to look at how the code handles those, but once I figure it out, I can try to copy that over
• Rotation circle based = I presume you mean it always rotates from the 0 = up point rather than from its current position? I should be able to add a toggle that determines if the rotation is relative to its position and add a step mode and a 0 button, but I'll need to figure out what's best here. I'll have to look at how it works.
• Rotations as Radians = I heavily agree it should be degrees. Radians is useful for calculation, but degrees is VASTLY more intuitive for UI. We can translate these values in the code so the display is easy to understand and remains flexible.
• Normalize View = I agree as well. With graphs I always like to normalize so the data is as clear as possible. Shouldn't be too hard. Get the max value and min value of the curves and add a little buffer to determine the view size. Just gotta see how it's done in the code.
• Scalar keyframes support frame labels = That would be ideal. Hopefully it's just a matter of making the frame base universal so the labels are part of it by default. If I'm understanding that correctly.

Yeah, I'll try to incorporate as many of these as I can. If I get stuck, we can discuss clarifying some of them further.

Keep in mind this is an open source project, you don't have to do everything at once, and you definitely don't have to do anything on your own. Start with the parts that you can figure out yourself, and if there's parts you don't understand... there's no shame in telling other people 'hey, this needs to be done by someone else'. For example, we let the people familiar with macs handle building mac deps.

In this particular case, the ones you are marking as Rotation circle based and Curves as Vectors are actually very complex, and I don't expect starting devs to be able to do this. I recommend looking at those last unless you have an epipany.

I presume you mean it always rotates from the 0 = up point rather than from its current position?

I didn't. I mean that if you go from 0° to 180° and then back to 0° again, it doesn't do a 360°, but just goes back the way it came. This is a bit on the tricky side, hence me suggesting we should delay it.

Yep, no problem! Yeah I'll do what I can, but if I get stumped, I'll definitely let everyone know how far I've gotten. It'll at least let anyone else who tries know what may or may not have worked. Still yeah, I won't do everything at once. I'll focus on each bullet one at a time. For now I'm focusing on exchanging the title bar. And yeah, those two sounded like the most complicated since they would involve larger changes than UI or interaction, but a fundamental change.

Ah and thanks for clarifying. So it jumps from 180 back to 0, preventing you from having like 270 degree rotations. I'll take your advice and save that one for last, but I think aside from the Bigger Toggles, most of the others I'll tackle after I hit the purely visual ones. Though Numerical Input shouldn't be too hard either. The rest will require some trial and error.

And certainly, given I'm somewhat busy with my IRL job and am mostly volunteering, by all means if anyone wants to take on any of the above, I'm subscribed to this and will happily step aside. From the tests I've done using other software, Krita is still by far the best art program out there (even better than Clip Paint Studio), so I'm more than happy to do what I can.