Remove APIs:
ges_track_element_set_locked
ges_track_element_is_locked
Those APIs where really not nice to use and were causing more issues
than solving them. If 2 time related properties of TimelineElement must
be different, then those element can *not* have the same parent.
Plus, with the new ges_container_group () API, we will recreate 1
GESClip containing the proper GESTimelineElements if it is the thing
to do.
WARNING: The plan is to remove unlocked track object APIs so this is
the first part of that process... that code was already broken, and
*needs* to be fixed anyway, better do it using new APIs
+ Fix tests (starting using GESTestClip instead of GESCustomClip)
Now the height is not only growing, but can also go down, as the value
is just simply computed
API:
GESContainer::compute_height virtual method
+ Fix tests (we still need a round of modernisation, making use of
assets where it makes sense)
There is no reason to use those method outside of GES, so remove them,
cleaning the API and making it easier for users.
Removed APIs:
-----------
* ges_clip_create_track_element
* ges_clip_create_track_elements
This way we let the possibility to the user to actually do it, but we avoid him to do it
without knowing it is absolutely not recommanded to.
API:
+ ges_uri_clip_asset_request_sync
... 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.
+ 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.
