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
When users (can be formatters) set timeline element names in the
default 'namespace' we need to update our counter to avoid setting
twice the same name on TimelineElements so afterward there is no
problem adding them in the GESTimeline
+ add a testcase to check that new code and fix leaks on the
existing testcases.
+ Sensibly enhance debugs
And fix all the tests as we need to wait for the project to be loaded
to check the reference count of the timeline (as we keep a ref on the
timeline in project to later emit "loaded" on idle).
If you want a custom clip then you have to subclass GESClip,
This class was pre historicall and only used for testing purposes, we
have GESTestClip for that.
https://bugzilla.gnome.org/show_bug.cgi?id=706855
Check if an object rthat has already been freed has been destroyed is not safe.
Add a helper function that uses weak reference to check that objects that are expected
to be destroyed when unrefing an object are actually destroyed.
The GNL API changed to go from a model where user could
enable/disable updates in the composition, which leaded to races
in many places, to a model where any positioning change in the
composition is not directly done but 'cached' and then the user
has to commit those changes so they become effective in the media
processing stack.
The new API in GES is pretty similare and is basically copy
pasting this new design.
We still need to see if in some context it would make sense to add
a mode where we would commit any changes ourself at the end of our
operation for basic use cases.
Removed APIs:
ges_timeline_enable_update
ges_timeline_is_updating
ges_track_enable_update
ges_track_is_updating
New APIs:
ges_track_commit
ges_timeline_commit
... Not the other way round.
+ Add and enhance debugging info on the way
The user should not be responsible for removing the GESTrackElements from
GESTracks, instead, removing it from a GESClip should imply removing
it from any GESTrack it is in.
This patch changes sensibly the behaviour when we remove a
GESTrackElement from a GESTrack, not remoing it from the GESClip it is
in. *But*, users should never remove a GESTrackElement from a GESTrack
anyway. The testsuite has been updated to that new behaviour.
Modifies some API:
ges_timeline_object_create_track_objects now take a GESTrackType instead of a
GESTrack as second argument, and return a GList instead of a boolean
ges_timeline_object_create_track_object now take a GESTrackType instead of a
GESTrack as second argument
+ timeline: Add a snapping-distance property
+ Bump the GLib dependency to 2.28 in the mean time as we need some functions from GSequence that only landed
+ Update the testsuite accordingly
API: GESTimeline:snapping-distance property
API: ges_timeline_object_edit
API: ges_timeline_object_ripple
API: ges_timeline_object_ripple_end
API: ges_timeline_object_roll_start
API: ges_timeline_object_roll_end
API: ges_timeline_object_trim_start
API: ges_track_object_edit
API: GESEdge enum
API: GESEditMode enum
