GNOME Bugzilla – Bug 619654
keyframeable effects / parameters interpolation
Last modified: 2013-09-30 19:13:45 UTC
When implementing effects this summer, we need to figure our a proper way to represent effect keyframes in the UI. Various ways of achieving this have been discussed, but there is no clear consensus yet AFAIK. There seems to be two competing paradigms for this: - "Effects and transitions are objects on the timeline" (that means keyframes would also be directly manipulated on the timeline) - "Effects are fundamentally per-clip or per-layer, and are keyframed in a interface separate from the timeline" (the approach used by most if not all editors out there) But this isn't just a matter of looks, it affects how the user interacts with the abstract concept off an effect's "effect range" (ie: clips/tracks vs "portions of time"), and also how gnonlin "thinks".
*** Bug 611199 has been marked as a duplicate of this bug. ***
*** Bug 611197 has been marked as a duplicate of this bug. ***
In the case of a "properties keyframes" widget (kind of a timeline with each property being represented as a "layer"), I would expect the following behavior: - Keyframes are created automatically whenever something changes - Individual keyframes can be deleted by double-clicking them - Tooltips explain the use of widgets when you hover them - Just like a mini timeline, you have a playhead that you can move around
Additional ways to delete keyframes: - right-clicking a keyframe and selecting "Remove keyframe" from a popup menu - selecting a keyframe and immediately pressing the Delete key Therefore, there is no need for a "Remove keyframe" button (and thus no need for the keyframe management toolbar that was initially in my mockups).