Bug 356540 - Krita Animation Beta - Moving First Frame Leaves Behind Blank Frame Instead of Empty
Summary: Krita Animation Beta - Moving First Frame Leaves Behind Blank Frame Instead o...
Status: RESOLVED LATER
Alias: None
Product: krita
Classification: Applications
Component: Animation (show other bugs)
Version: 2.9.10
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-12-12 04:37 UTC by sayantan.chaudhuri+kde
Modified: 2016-01-22 13:20 UTC (History)
2 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 sayantan.chaudhuri+kde 2015-12-12 04:37:47 UTC
As of the 2.9.10 build of the animation beta, bug #356057 [https://bugs.kde.org/show_bug.cgi?id=356057] is resolved, and the first frame of the animation can be moved and copied.

But now, moving the first frame leaves behind a blank frame instead of an empty frame which moving any other frame leaves behind.

Reproducible: Always

Steps to Reproduce:
1. Create some frames
2. Draw something on the first frame.
3. Select and then drag the first frame to any other frame.

Actual Results:  
The destination frame is overwritten with the contents of the first frame. But in the first frame's position a blank (white) frame is left behind.

Expected Results:  
The destination frame is overwritten with the contents of the first frame. And in the first frame's position an empty (grey/blue) frame is left behind.
Comment 1 Halla Rempt 2015-12-12 14:25:54 UTC
Added to https://phabricator.kde.org/T1141
Comment 2 Dmitry Kazakov 2015-12-14 14:12:17 UTC
Hi, Sayantan!

It is done intentionally that the zero frame is present on the timeline. We will be able to hide it only after 3.0. What exactly is your problem, that the frame is seen on the timeline or that the frame has some opaque content after being deleted?
Comment 3 sayantan.chaudhuri+kde 2015-12-14 16:41:33 UTC
Hullo Dmitry. Now that I think about it, I see how the first frame can indeed be tricky!

In my case, the problem is indeed that an opaque/blank frame interrupts my loop that was otherwise flowing seamlessly before moving that one frame. But then, the end frame would not have "held" to the first frame anyway, so I shouldn't've expected that. 

I am convinced that I can personally work with an extra step of alt-dragging the animation a few steps back after moving the first frame. At least until 3.0! :D



Shall I mark this issue as resolved, or will this be as-intended or won't-fix? I can't mark those status tags as a submitter, right?
Comment 4 Dmitry Kazakov 2016-01-22 13:20:18 UTC
I'll mark this bug as LATER. We will probably fix it after 3.0 release.