We just need to make sure they are always serialized in the right
order (which is the case) and de serializing them will lead to the
right behaviour.
We should not serialize the priority as the priority of the source
itself depends on the action having been done on the parent clip,
and we do not serialize the source priorities (and should not, GES
should just do the right thing).
Differential Revision: https://phabricator.freedesktop.org/D491
Summary:
g_file_new_for_uri never fails so GFile always has valid pointer.
And fix a bug of double unref from D303.
Reviewers: thiblahute
Differential Revision: https://phabricator.freedesktop.org/D310
Summary:
Valgrind reports trivial leakages related to handling
objects and their converted strings.
Reviewers: thiblahute
Differential Revision: https://phabricator.freedesktop.org/D303
GstStructureForeachFunc has a gboolean return value,
and the foreach function will stop unless we return
TRUE here. This meant it was potluck whether all
properties in the structure got set or not.
Fixes setting of text overlay clip text property
in particular.
https://bugzilla.gnome.org/show_bug.cgi?id=743874
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
This avoid segfault as we are not guaranteed that the formatter will
not be destroyed in the meantime.
+ Minor cleanup of handling of private members
https://bugzilla.gnome.org/show_bug.cgi?id=724337
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
+ Fix tests as necessary (Do not use agingtv as it can be "applied" on any TrackType
and is not representative of what happens IRL)
We already had the infrastructure so the user can have the control over where to add
the elements (through the "select-track-for-object" signal). We now make use of that
signal everytime a GESClip is added to a GESTimelineLayer. This make user's life easier,
and object responsability clearer.
