View Bug Details

IDProjectCategoryView StatusLast Update
0000737DCP-o-matic[All Projects] Bugspublic2016-07-04 14:12
Reporterrobn 
Assigned Tocarl 
PrioritynormalSeveritytweakReproducibilityalways
Status resolvedResolutionfixed 
Platform64 bit LinuxOSFedoraOS Version22
Product Version 
Target Version2.6.0Fixed in Version 
Summary0000737: Suggestions for improved trim behaviour
DescriptionThe behaviour of the trim buttons in the Timing tab of Content could be made
a bit more logical/practical. Currently (version 2.4.15) they seem to work
like this:

"Trim up to current position" means:
        - remove all frames before the current frame.
        - the current frame is kept.

"Trim after current position" means:
        - remove all frames after the current frame.
        - the current frame is removed too.


Here are some suggestions to make things better:

1. Keep the current frame with "Trim after current position" too.
    (eg. both the "Trim up to.." & "Trim after.." button then always
    keep the current frame).

2. Always try to stay on the current frame with the preview (of course
    this is not possible when it is removed by a start or end trim)

    With the current code trimming with the trim buttons always results
    in a frame jump. With "rule 1." the current frame is never removed,
    so we can stay on it.

    With a trim via "Trim from start" we always get a frame jump too.
    If the current frame is not removed by it, we should stay on it.

    But with "Trim from end" we stay on the current frame (if it is not
    removed). I think this is the preferred behaviour.

    If the current frame is deleted by a trim action we should get
    this frame as the new current frame:

        end trim --> the last frame (from what's left)
        start trim --> the first frame (from what's left)

    If there is multiple content it might be a good idea to disable
    the "Trim up to.." & "Trim after.." buttons if the current frame
    is not in the currently selected content?
Steps To ReproduceI tested with a directory with sequential images. I overlayed the frame numbers
in the images for easier testing.
TagsNo tags attached.
Estimated work requiredSmall

Relationships

Activities

carl

2015-11-09 00:44

administrator   ~0000961

Thanks for the suggestions. They are implemented in b6a281b4ba1d5e2b91ae3d54e073ee88308f61b6 and 294704d07de1fd6981362d85a26e4a83a6ef08fa which will be in 2.5.1.

robn

2015-11-10 21:37

reporter   ~0000973

The "Trim up to.." & "Trim after.." buttons seem to work fine now.

But with "Trim from start" & "Trim from end" things are not working
as expected yet (assuming you agree with my suggestions!).

Let's assume an example of 100 frames (numbered 1 - 100).
(The frame numbers are the numbers of the frames in the content,
not the number the preview window gives them!)

some examples:

- cur_pos=10, trim 5 frames from start ==> cur_pos=15 (expected unchanged: 10)
- cur_pos=10, untrim all frames from start ==> cur_pos=5 (expected unchanged: 10)
- cur_pos=5, trim 10 frames from start ==> cur_pos=15 (expected first of the frames left: 11)
- cur_pos=90, trim 5 frames from end ==> cur_pos=90 OK!
- cur_pos=90, untrim all frames from end ==> cur_pos=90 OK!
- cur_pos=95, trim 10 frames from end ==> cur_pos=?? (black preview) (expected last of the frames left: 90)

carl

2015-11-10 23:28

administrator   ~0000974

Thanks for testing things. Your further points should be ok in 8cc825a798d9a457b89f968a57d3b6a16f6cedfe (2.5.2).

Bug History

Date Modified Username Field Change
2015-11-03 02:28 robn New Bug
2015-11-05 09:34 carl Estimated work required Average => Small
2015-11-05 09:34 carl Status new => acknowledged
2015-11-05 09:34 carl Target Version => 2.6.0
2015-11-09 00:44 carl Note Added: 0000961
2015-11-09 00:44 carl Status acknowledged => resolved
2015-11-09 00:44 carl Resolution open => fixed
2015-11-09 00:44 carl Assigned To => carl
2015-11-10 21:37 robn Note Added: 0000973
2015-11-10 21:37 robn Status resolved => feedback
2015-11-10 21:37 robn Resolution fixed => reopened
2015-11-10 23:28 carl Note Added: 0000974
2015-11-10 23:28 carl Status feedback => resolved
2015-11-10 23:28 carl Resolution reopened => fixed