Targets exported in https://invent.kde.org/lsegovia/seexpr/-/commit/ef6d1ae2a618c55bdb42337340777c145ea0f672.
I will bundle this tag in an upcoming commit.

Built-in functions have been extracted in https://invent.kde.org/lsegovia/seexpr/-/commit/2dd6799933e86e7e25d1d9a8e5e5a3f7bed6d138 .
Infrastructure changes for future inclusion in KDE have been applied in https://invent.kde.org/lsegovia/seexpr/-/commit/5e8be062ee48fae920ceefe4a3d5aded44d2b9c9 .

UI strings have been extracted in https://invent.kde.org/lsegovia/seexpr/-/commit/7a28649a47dbd78ce891955b14e7259f8b5f3f2a.

Well having shortcuts divided in 2 files does not help users manage them too. it takes alot of effort to setup your own custom layout and discover what are the keys are connected to exactly (shortcuts or canvas inputs).

@emmetoneill , thanks for the feedback!

Hey @lsegovia, @eoinoneill and I just spent a while testing out your SeExpr patch and I want to share some of our initial reactions.

Apologies for the edit, I've now added all related commits. (I should remember to ref this task.)

It would be THE feature! One of main reasons why I mostly use procreate on the ipad. Because it allows recording of the painting progress without zooming, rotation, etc...

Hi, @emmetoneill and @eoinoneill!

made a breeze version to make it more KDE styled and more different to blender

Very nice, thank you!

A suggestion from Ahmet T:

:'(

Yes; the only real problem is making sure that the keyframes work after saving and reopening (they are saved correctly, but the playback didn't seem work). This feature can work without messing with curves; it would be extremely beneficial if they were improved, but one can work without them.

This was worked in https://invent.kde.org/kde/krita/-/merge_requests/281 - and it was merged, so I'm going to close this task.

Get in touch with Wolthera when it comes to documenting the .kra format: she has started doing that for the manual, so it might be useful to help fill out the specification she's set up.

I just added you two to this ticket. It relates to a "tweening" animation feature that was in development. Now that the animation cache stuff is figured out, this might be able to be dusted off and resurrected.

• yes for pixel art that could be great too!

In T12769#226607, @Bollebib wrote:

i saw this proposal

and i mainly agree with it , if we could eliminate that docker that would maybe be good.

i saw this proposal

In T12769#225945, @dkazakov wrote:

Hi, @emmetoneill!

I've got a reply from @Bollebib about your implementation of "Selection next/prev sibling" feature. He reports it works as expected. The only worry he has is that he wanted to use it in conjunction with this feature that is not yet implemented :) https://bugs.kde.org/show_bug.cgi?id=377468

In T12769#225732, @eoinoneill wrote:

@Bollebib I think doing that wouldn't be too difficult but would require a new Export UI for the compositions docker to accommodate for more advanced settings (kind of like the existing Animation Exporter UI?)

The filters thing is arguably easier and the fact it doesn't store the state I would consider a bug. There's text-based metadata in every filter layer so saving the settings applied to a filter should be relatively trivial. (famous last words. :) )

Out of curiosity though, @Bollebib , do you think there's potential overlap between the features of the current compositions docker and the proposed storyboard docker T12819 that are worth noting? It seems to me like the original intention of this dockers design was to manage multiple compositions in one krita file, which seems to overlap the concept of storyboarding in general. It might be good to unify the vision of this docker with the proposed storyboard docker perhaps?

I've got a reply from @Bollebib about your implementation of "Selection next/prev sibling" feature. He reports it works as expected. The only worry he has is that he wanted to use it in conjunction with this feature that is not yet implemented :) https://bugs.kde.org/show_bug.cgi?id=377468