Open darbyjohnston opened 2 weeks ago
codecov-commenter
commented
2 weeks ago Attention: Patch coverage is 92.59259% with 2 lines in your changes missing coverage. Please review.
Project coverage is 81.69%. Comparing base (
c0e97b0) to head (3a61e3c). Report is 12 commits behind head on main.
darbyjohnston
commented
2 weeks ago @jminor Sorry, I managed to mess up the git history on the previous PR while trying to update with the latest changes from main. I created this new PR as a replacement.
I believe your last comment was about using trimmed_range_in_parent() and testing with a source range on the track? I didn't realize that tracks could have source ranges, what would that test look like?
jminor
commented
2 weeks ago There's an example of a track with a source_range in Figure 3 here: https://opentimelineio.readthedocs.io/en/stable/tutorials/otio-timeline-structure.html In that diagram, Track-003 is offset by using a source_range with a negative start time. A simpler use case would be to use a track's source range to just trim a nested track to a sub-range of the whole track.
There's also an example of a stack with a source_range in Figure 4 on that same page. In that case the source_range is used to trim the nested stack. Although rare, the source_range could be set on the top level stack of a timeline also.
darbyjohnston
commented
1 week ago Thanks, those figures were very helpful; I guess I should have checked there first. :)
I changed the code to use trimmed_range_in_parent() and added extra C++ tests that put various source ranges on the track. If the C++ tests look OK I will update the Python tests to match.
Fixes #1652
This PR is a replacement for #1755 which has some trouble with the git history.
After some investigation, it looks like the find_children() function was not working with stacks when given a search range. To fix this, an override is added for the function children_in_range() that works with "stacks" of children.