Synfig Issue Tracker ~ [OPEN] #457 - Disabled keyframes doesn't work well with drag and drop operations

Synfig Issue Tracker

OPEN Bug report #457 - Disabled keyframes doesn't work well with drag and drop operations

Posted Jun 07, 2013 - updated Sep 24, 2014

Votes

Issue details

Type of issue

Bug report Unknown issue type
Status

Confirmed

Status not determined
Assigned to

djay

djay
Offline

This user was last seen online at Apr 23, 2016 - 14:26

Show user details

Close this menu

Not assigned to anyone
Progress
Type of bug

Not triaged
Likelihood

Not triaged
Effect

Not triaged
Posted by

Carlos López

genete
Offline

This user was last seen online at Feb 04, 2016 - 22:57

Show user details

Close this menu
Owned by

Not owned by anyone
Estimated time

No time Not estimated
Time spent

No time No time spent
Category

User interface Not determined
Resolution

Not determined
Priority

Not determined
Reproducability

Not determined
Severity

Not determined
Targetted for

Not determined
Tags

keyfarme drag drop disabled enabledNot determined
Difficulty

Not determined

Issue description

After play a while with some disabled keyframes and non disabled keyframes with the drag and drop operations it is noticed that:

When ALT-drag and drop a disabled keyframe, its time is not updated.
Click and drag enabled keyframes over disabled keyframes messes up the disabled keyframes position on the keyframe list.

Steps to reproduce this issue

Disable a keyframe and play with drag and drop and ALT-drag and drop with it and with other not disabled keyframes.

Show system-generated comments

Comment posted by

Carlos López

Jun 07, 11:51

A file was uploaded. Messed up keyframe list

This comment was attached:

Notice how the previous to last keyframe has a length of zero and the times of the two last keyframes are wrong.

The keyframe widget is correctly rendered though.

Comment posted by

Carlos López

Dec 18, 12:00

Can we target this for 0.65.0?

Comment posted by

djay

Sep 02, 14:45, in reply to comment #5

I think we can !

https://github.com/morevnaproject/synfig/pull/10

Carlos López wrote:

Can we target this for 0.65.0?

Comment posted on behalf of

djay

Sep 02, 16:02

The issue was updated with the following change(s):

This issue has been closed
The status has been updated, from New to Done.
This issue's progression has been updated to 100 percent completed.
The resolution has been updated, from Not determined to RESOLVED.
Information about the user working on this issue has been changed, from djay to Not being worked on.

Comment posted by

Konstantin Dmitriev

Sep 09, 15:27

Hello djay! I have tested proposed solution and found a regression.

Please follow those steps to reproduce:

Create 3 keyframes: at 0f, at 10f and at 20f
Disable keyframe at 10f
Create circle
Enable animation mode
Go to 10f and move circle -> waypoint will appear (as it should)
Now ALT-Drag keyframe at 10f. Result: it will be moved together with keyframe at 20f (and that's correct), BUT it will also move waypoint at 10f. That mean, the disabled keyframe acts as enabled. And that's not correct.

#10

Comment posted on behalf of

djay

Sep 10, 09:36

The issue was updated with the following change(s):

The status has been updated, from Done to New.
This issue has been reopened
The resolution has been updated, from RESOLVED to Not determined.
This issue's progression has been updated to 0 percent completed.

#11

Comment posted by

djay

Sep 12, 12:25, in reply to comment #9

not a regression, it's doing the same since 0.64.1 , but anyway...

Konstantin Dmitriev wrote:

I have tested proposed solution and found a regression.

#12

Comment posted by

Konstantin Dmitriev

Sep 15, 05:16, in reply to comment #11

djay wrote:

not a regression, it's doing the same since 0.64.1 , but anyway...

Yes, you right. In fact, this raises a question: how should we deal with disabled keyframes when doing ALT+drag?

#13

Comment posted by

djay

Sep 15, 10:13, in reply to comment #12

I think disabled kf should react has disabled kf ;-)

I think that moving disabled kf with Alt-Drag must react has moving (Drag) disabled kf : Waypoints must stay in place.

Currently, i'm working on fixing that. Tell me if it's not useful.

Konstantin Dmitriev wrote:

Yes, you right. In fact, this raises a question: how should we deal with
disabled keyframes when doing ALT+drag?

#14

Comment posted on behalf of

djay

Sep 15, 10:13

The issue was updated with the following change(s):

The status has been updated, from New to Confirmed.
This issue's progression has been updated to 10 percent completed.

#15

Comment posted by

Konstantin Dmitriev

Sep 15, 10:44, in reply to comment #13

djay wrote:

I think disabled kf should react as disabled kf ;-)

I think that moving disabled kf with Alt-Drag must react has moving (Drag)
disabled kf : Waypoints must stay in place.

Currently, i'm working on fixing that. Tell me if it's not useful.

Yes, it is fine. I just was thinking about the ways to workaround the issue by introducing restrictions. (I had idea to forbid Alt+drag for disable d keyframes, but I'm not sure if it's right way to go) ^__^

Anyway, that would be great if you will fix it in the way as you described! ^___^

#16

Comment posted by

djay

Sep 15, 15:44, in reply to comment #15

Hummm ... but for previous or next kf, what must be done ?

http://pix.toile-libre.org/upload/original/1410795600.gif

Konstantin Dmitriev wrote:

djay wrote:
I think disabled kf should react as disabled kf ;-)

I think that moving disabled kf with Alt-Drag must react has moving (Drag)
disabled kf : Waypoints must stay in place.

Currently, i'm working on fixing that. Tell me if it's not useful.

Yes, it is fine. I just was thinking about the ways to workaround the issue
by introducing restrictions. (I had idea to forbid Alt+drag for disable d
keyframes, but I'm not sure if it's right way to go) ^__^

Anyway, that would be great if you will fix it in the way as you described!
^___^

#17

Comment posted by

Konstantin Dmitriev

Sep 17, 07:49, in reply to comment #16

djay wrote:

Hummm ... but for previous or next kf, what must be done ?

"previous or next kf" - do you mean "previous or next WAYPOINT"?

#18

Comment posted by

djay

Sep 17, 09:36, in reply to comment #17

Yes, sorry, WAYPOINT... !

#19

Comment posted by

Konstantin Dmitriev

Sep 24, 10:44, in reply to comment #18

OK, I've been thinking a lot about that and here's my thoughts.

The meaning of "disabled keyframe" is following: it is a keyframe, which doesn't affect current document. Following this statement, we can conclude following statements about behavior of disabled keyframe:

ALT+drag of disabled keyframe shouldn't affect anything. In other words, ALT+drag of disabled keyframe should act as a regular drag, without affecting any other elements.
ALT+drag of regular keyframe should move ALL keyframes after it (both enabled and disabled). This is because the enabled keyframe is a high-priority object - it controls waypoints and disabled keyframes. I think this is OK from usability point of view.

Considering assumptions above, I think we need to make following changes to resolve this issue:

Disable ALT+drag functionality for disabled keyframes. It should act as a normal drag.

* Username
* Display name
The "display name" is the name shown to others
Real name
* E-mail address
* Confirm e-mail

Welcome to The Bug Genie

Really delete this comment?

Really delete this comment?

Really delete this comment?

Really delete this comment?

Really delete this comment?

Really delete this comment?

Really delete this comment?

Really delete this comment?

Really delete this comment?

Really delete this comment?

Really delete this comment?

Really delete this comment?

Really delete this comment?

Really delete this comment?

Really delete this comment?

Really delete this comment?

Really delete this comment?

Really delete this comment?

Really delete this comment?

Username
Password