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.
