Per https://krita-artists.org/t/auto-frame-mode-no-longer-exists/48439/5 SUMMARY As of 5.1.0, using the transform/move tool on content from a previous frame onto a selected empty column doesn't automatically add a new frame. STEPS TO REPRODUCE 1. Add the first frame. 2. Draw something. 3. Select the drawn content. 4. Select a new empty column. 5. Translate the content with move/transform tool. OBSERVED RESULT A new frame isn't automatically made. EXPECTED RESULT A new frame should be automatically made. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Debian sid KDE Plasma Version: 5.25.5 KDE Frameworks Version: 5.98.0 Qt Version: 5.12.12 (appimage)
Since this issue starts occurring as of 5.1.0, marking as a regression.
Another report: https://krita-artists.org/t/transform-tool-doesnt-create-new-frame-in-animation/49821 Setting to confirmed.
I confirm I noticed the same issue, and it's a regression for my workflow (reproduced starting from 5.1.0). The issue is actually that now, it seems only actions from paint tools (from Freehand brush to Multibrush) trigger the Auto-Frame, while it used to be triggered by any edit action on the canvas. So now, other actions just perform on the previous/currently displayed frame, which feels unexpected and confusing... I used this feature extensively, for example using the Del. shortcut to create a new blank frame, or using the transform tool to create a new frame with transformed content. But in general it makes sense to have this working for any action that edits the canvas content. Please bring back this feature.
For the record, this is purely a regression not an intentional removal. It has to do with the fact that we removed the autokey from the KisTransaction and now have to manually reinstate autokey to any feature that was relying on the "automatic" behavior of KisTransaction. This is something I'll try to double check with dmitry over, since I wasn't really sure about removing this from transaction since it means we now have to repeat ourselves a few times in various parts of the codebase. I will try to make the changes as clean as possible though.
Git commit d4fa022e83a93fbc4d447f06a02c62d810534d44 by Eoin O'Neill. Committed on 22/11/2022 at 08:06. Pushed by eoinoneill into branch 'master'. Autokey Fix Part II There are also some cases where the actual autokey setting was being ignored. This is now fixed by actually respecting user's autokey setting. This should fix most issues (hopefully all issues) around autokey regressions. Please reopen this bug or a new bug if these issues return once more. M +17 -14 libs/ui/tool/strokes/move_stroke_strategy.cpp M +14 -11 plugins/tools/basictools/strokes/move_selection_stroke_strategy.cpp M +23 -20 plugins/tools/tool_transform2/strokes/inplace_transform_stroke_strategy.cpp M +21 -18 plugins/tools/tool_transform2/strokes/transform_stroke_strategy.cpp https://invent.kde.org/graphics/krita/commit/d4fa022e83a93fbc4d447f06a02c62d810534d44
Git commit 305fd3fb947a0c11d9219a56555dafaf5162fd31 by Eoin O'Neill. Committed on 22/11/2022 at 07:47. Pushed by eoinoneill into branch 'master'. Add a plethora of missing autokey implementations for movement. There are two problems right now (in general) with autokey compared to previous versions of Krita. 1) Krita was originally heavily reliant on using KisTransactions for autokeying content in a way that essentially inherited. Since dmitry made some changes to the way transactions are applied during brush strokes that allowed them to be multi threaded, this behavior had to be fixed in a previous commit to prevent a data race resuling in a nasty crash on autokey. This means we lost some of the "automatic" autokey behavior and it needs to be reimplemented in a few key strategies in order to achieve parity with older versions. In the case of this particular bug fix, I missed a few edge cases when dealing with raster keyframes. 2) As a result of 1, there's a lot of areas of the code base where we're definitely repeating ourselves. Long term, we should really try to come up with a logical way to reuse any autokey related stroke strategy behavior so that any stroke that needs to respect users autokey wishes can do so with just a few function calls or configurations. For now, there's no real issue with repeating ourselves just to fix regressions. M +19 -0 libs/ui/tool/strokes/move_stroke_strategy.cpp M +3 -0 plugins/tools/basictools/kis_tool_move.cc M +19 -0 plugins/tools/basictools/strokes/move_selection_stroke_strategy.cpp M +13 -0 plugins/tools/tool_transform2/strokes/inplace_transform_stroke_strategy.cpp M +12 -0 plugins/tools/tool_transform2/strokes/transform_stroke_strategy.cpp https://invent.kde.org/graphics/krita/commit/305fd3fb947a0c11d9219a56555dafaf5162fd31
Git commit df68b31b93c966cc8e9d8486e2a54eacac8d0c4b by Emmet O'Neill, on behalf of Eoin O'Neill. Committed on 08/12/2022 at 04:12. Pushed by emmetoneill into branch 'krita/5.1'. Add a plethora of missing autokey implementations for movement. There are two problems right now (in general) with autokey compared to previous versions of Krita. 1) Krita was originally heavily reliant on using KisTransactions for autokeying content in a way that essentially inherited. Since dmitry made some changes to the way transactions are applied during brush strokes that allowed them to be multi threaded, this behavior had to be fixed in a previous commit to prevent a data race resuling in a nasty crash on autokey. This means we lost some of the "automatic" autokey behavior and it needs to be reimplemented in a few key strategies in order to achieve parity with older versions. In the case of this particular bug fix, I missed a few edge cases when dealing with raster keyframes. 2) As a result of 1, there's a lot of areas of the code base where we're definitely repeating ourselves. Long term, we should really try to come up with a logical way to reuse any autokey related stroke strategy behavior so that any stroke that needs to respect users autokey wishes can do so with just a few function calls or configurations. For now, there's no real issue with repeating ourselves just to fix regressions. (cherry picked from commit 305fd3fb947a0c11d9219a56555dafaf5162fd31) M +19 -0 libs/ui/tool/strokes/move_stroke_strategy.cpp M +3 -0 plugins/tools/basictools/kis_tool_move.cc M +19 -0 plugins/tools/basictools/strokes/move_selection_stroke_strategy.cpp M +13 -0 plugins/tools/tool_transform2/strokes/inplace_transform_stroke_strategy.cpp M +12 -0 plugins/tools/tool_transform2/strokes/transform_stroke_strategy.cpp https://invent.kde.org/graphics/krita/commit/df68b31b93c966cc8e9d8486e2a54eacac8d0c4b
Git commit 1c1dff1c4a63e380b743b45ee2c7c9db8a94957c by Emmet O'Neill, on behalf of Eoin O'Neill. Committed on 08/12/2022 at 04:13. Pushed by emmetoneill into branch 'krita/5.1'. Autokey Fix Part II There are also some cases where the actual autokey setting was being ignored. This is now fixed by actually respecting user's autokey setting. This should fix most issues (hopefully all issues) around autokey regressions. Please reopen this bug or a new bug if these issues return once more. (cherry picked from commit d4fa022e83a93fbc4d447f06a02c62d810534d44) M +17 -14 libs/ui/tool/strokes/move_stroke_strategy.cpp M +14 -11 plugins/tools/basictools/strokes/move_selection_stroke_strategy.cpp M +23 -20 plugins/tools/tool_transform2/strokes/inplace_transform_stroke_strategy.cpp M +21 -18 plugins/tools/tool_transform2/strokes/transform_stroke_strategy.cpp https://invent.kde.org/graphics/krita/commit/1c1dff1c4a63e380b743b45ee2c7c9db8a94957c