Bug 392233 - Animation Frames in 4.0.0 can not be removed after playing.
Summary: Animation Frames in 4.0.0 can not be removed after playing.
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: Animation (show other bugs)
Version: 4.0
Platform: Debian stable Linux
: NOR normal
Target Milestone: ---
Assignee: Dmitry Kazakov
URL:
Keywords:
: 392210 392211 392306 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-03-23 14:40 UTC by Ahab Greybeard
Modified: 2018-04-05 07:01 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ahab Greybeard 2018-03-23 14:40:45 UTC
This has been observed in Krita 4.0.0 appimage.

If frames are created, by Copying from another frame or by the New Frame option, then these frames can be Removed (using the right-click and selecting Remove Frame). 

However, if nine or more frames are created, then after playing the animation the frames can not be Removed by using the Remove Frame action.

The mitigation for this is to drag the frame to the end of and beyond the final frame of the animation to 'dump' location, which will empty its old location. Many frames, if required to be removed, can be dragged to the same place.
Comment 1 Ahab Greybeard 2018-03-25 12:04:44 UTC
As reported by a forum contributor, another mitigation is to create a Keyboard Shortcut (such as F12 as an example) for Remove Frame.

https://forum.kde.org/viewtopic.php?f=139&t=151625

I confirm that this works as a mitigation.
Comment 2 Scott Petrovic 2018-03-25 16:59:59 UTC
Can you give specific steps to repeat this for you? 

I am trying to do the following

1. Create a new Document and change to change to animation workspace
2. Add an animation keyframe to start the animation frames
3. click around the timeline and create 10 keyframes by right clicking and selecting "Copy keyframe"
4. Right click a keyframe and press "remove keyframe"

Doing that seems to allow me to remove a keyframe
Comment 3 Scott Petrovic 2018-03-25 17:11:35 UTC
*** Bug 392306 has been marked as a duplicate of this bug. ***
Comment 4 Scott Petrovic 2018-03-25 17:12:43 UTC
*** Bug 392211 has been marked as a duplicate of this bug. ***
Comment 5 Ahab Greybeard 2018-03-25 17:16:25 UTC
The behaviour seems to be inconsistent.

I just did what you did, then I played it which seems to be an aspect of initiating the fault. After that I also could Remove Frame.

(However, I do New Frame at frame-0 then Copy Frame after that. I've not used the Keyframe facility which I understand is for 'tweening Opacity changes??)

However, if I used Copy Frame to extend this arrangement to frame-16, then played it (then stopped it), I could not then Remove Frame using right click.
Comment 6 Bollebib 2018-03-26 09:59:48 UTC
yes this seems to happen AFTER i press playback 
And using the docker to remove frames works ONLY on a single frame,not on a RANGE of frames,for me.



The playback has changed and seems a bit buggy for me compared to before,maybe its related?
Playback also doesnt update correctly when creating new frames, before you had to just pressy play and it would repopulate the cache,now you need to clear the cache manually with éisolate layeré or something similar. might be seperate issue
Comment 7 Dmitry Kazakov 2018-03-28 18:28:03 UTC
Git commit fd31bc71f7cf273bb1e46909a3f1f8c50b847ad6 by Dmitry Kazakov.
Committed on 28/03/2018 at 18:27.
Pushed by dkazakov into branch 'master'.

When cloning node (on autosaving) we should initialize *own* channels, not the source ones :)

M  +1    -1    libs/image/kis_node.cpp

https://commits.kde.org/krita/fd31bc71f7cf273bb1e46909a3f1f8c50b847ad6
Comment 8 Dmitry Kazakov 2018-03-29 16:58:17 UTC
*** Bug 392210 has been marked as a duplicate of this bug. ***
Comment 9 Halla Rempt 2018-04-03 11:47:52 UTC
Git commit e858b6b2e958a531c0cafcae49cd71299e676742 by Boudewijn Rempt, on behalf of Dmitry Kazakov.
Committed on 03/04/2018 at 11:18.
Pushed by rempt into branch 'krita/4.0'.

When cloning node (on autosaving) we should initialize *own* channels, not the source ones :)
(cherry picked from commit fd31bc71f7cf273bb1e46909a3f1f8c50b847ad6)

M  +1    -1    libs/image/kis_node.cpp

https://commits.kde.org/krita/e858b6b2e958a531c0cafcae49cd71299e676742
Comment 10 Dmitry Kazakov 2018-04-05 07:01:41 UTC
*** Bug 392559 has been marked as a duplicate of this bug. ***