In some cases when rippling clip we could get the algo lost because
a transition existed between two clips (for example at the end of c1
and at the begining of c2) but while rippling it would have required
a transition at the end of c2 and beginning of c1, and we were properly
not destroying the old one (as the two clips were in the moving context)
but we were still creating the other transition in the end...
Reviewed-by: Alex Băluț <alexandru.balut@gmail.com>
Differential Revision: https://phabricator.freedesktop.org/D1362
Computation was not taking into account the fact that the start of
the element being moved could be at the middle of a group and not
necessarily at the start!
Fixes T7544
Reviewed-by: Alex Băluț <alexandru.balut@gmail.com>
Differential Revision: https://phabricator.freedesktop.org/D1282
In case effects have been added priorites might become wrong,
but until the timeline is not commited, it does not matter.
Make sure all priorities are correct before commiting compositions
Differential Revision: https://phabricator.freedesktop.org/D1277
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
And reuse the same previously created element when adding the clip
back to a layer, avoiding losing all setting done on clip children
in that situation
This is a behaviour change but previous behaviour was actually totally
unexpected and people working around that weird behaviour will moste
probably not care about that change
Differential Revision: https://phabricator.freedesktop.org/D1094
This is formally an API break but I am sure no one ever used that and
we should make sure the method is removed as soon as possible because
it has no reason to be exposed.
In the GESTimeline, TrackElement addition to a clip might get cancelled
(and thus the element gets removed), we need to make sure users do not
get wrong signals.
Also document the fact that user should connect to container::child-added
with g_signal_connect_after.
We should never let 3 objects to overlap at a same position, for that
we introduce a "rollback" feature and whenever such an editing happens,
we rollback object position to whatever it was before the move.
In case of groups, we can have track elements that do not belong
directly to the moved_trackelements but will be moved as others. Never
create transition to all object that have a start > moving group start.
Summary:
+ [API] GESTrack::commited signal.
+ [API] ges_track_commit_sync
We were emitting commited when timeline_commit was called, which
wasn't very helpful. This commit makes it so we emit commited once
all the compositions have actually been commited.
We also add a synchronous commit method to spare the user
the need to connect to the signal and wait, and update the
documentation.
Reviewers: thiblahute
Differential Revision: http://phabricator.freedesktop.org/D83
I got some trouble with
arc land
and I wanted to push the 3 commit coming after this revert as 3
different commits but they ended up being all squash into one single
commit, which is clearly not cool for later bisecting and blaming.
Reverting that commit and re pushing those 3 commits as they were
supposed to be.
This reverts commit 9fe15ef435.
They were not serialized until now.
That implies several changes:
* Override GESTimelineElement [start, inpoint, duration] properties in
GESGroup to ensure that those properties are not serialized as they
should not be.
* Rename GESBaseXmlContainer->clips field to
GESBaseXmlContainer->containers as the hashtable now contains Groups
https://bugzilla.gnome.org/show_bug.cgi?id=709148
In case we are not in a PLAYING state and the project is loaded, the
only thing that should be done is to fill the gaps and this way when the
composition get to PLAYING, their initialization will be enough to get
everything on track.
