These tests expose some of the new editing behaviour in timeline
tree. In particular, we test:
+ edits for clips within groups within a group
+ that an edit can succeed if a snap allows it to
+ that snapping occurs at a specific point, and that we alternate
between one call to snapping-started and one call to snapping-ended
with corresponding values
+ that an edit can fail if a snap causes it to
+ no snapping is released when an edit fails
+ We tests for the expected changes, and otherwise check that the
configuration of the timeline has remained unchanged
+ The timeline configuration remains the same when an edit fails
+ That each clip overlap has a corresponding auto-transition
+ That particular auto-transitions are created when a new overlap is
formed
+ That particular auto-transitions are destroyed when an overlap ends
+ That auto-transitions are not replaced when two clips move but
maintain their overlap
+ That the timeline does not contain any unaccounted for clips
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-editing-services/-/merge_requests/169>
We were implementing the logic for moving/trimming elements specific
to SourceClip but this was not correct ass the new timeline tree allows
us to handle that for all element types in a generic and nice way.
This make us need to have groups trimming properly implemented in the
timeline tree, leading to some fixes in the group tests.
This adds tests for the various cases known to not be handled properly
by the previous code.
Fixes https://gitlab.freedesktop.org/gstreamer/gst-editing-services/issues/92
Subprojects simply consist of adding the GESProject
to the main project asset list. Then those are recursively
serialized in the main project in the <asset> not, when deserializing,
temporary files are created and those will be used in clips
as necessary
This is implemented on top of a Tree that represents the whole timeline.
SourceClips can not fully overlap anymore and the tests have been
updated to take that into account. Some new tests were added to verify
that behaviour in greater details
Auto transition when having 3 overlapping clips in a same point in the
timeline is not supported as we can't handle it in a nice way. Before we
to avoid creating 2 overlapping transitions (which is plain broken in
NLE) were completely disabling `auto-transition` and removing all
auto-transitions in the timeline but this is pretty weird for the end
user. This commit changes and now makes sure 2 transitions are not
created in the same place.
Also cleanup previous test case.
When removing an effect from a clip, first the notify::priority signals
were being emitted for the remaining effects which changed priority, and only
at the end the child-removed signal. Now the child-removed signal is emitted
first.
In the (now tested) scenario where we have a transition on the right
side of a clip we are splitting, auto transitions can't be created
because we resize the clip after adding the new one, meaning that
there are 3 elements in the "transition zone", we need to force
auto transition creation after the splitting.
Fixes https://gitlab.gnome.org/GNOME/pitivi/issues/2142
Had to separate timeline_emit_group_added from timeline_add_group
to avoid emitting group-added when the project is being loaded.
Reviewed-by: Thibault Saunier <thibault.saunier@collabora.com>
Differential Revision: https://phabricator.freedesktop.org/D1302
