View Bug Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000737||DCP-o-matic||[All Projects] Bugs||public||2015-11-03 02:28||2016-07-04 14:12|
|Platform||64 bit Linux||OS||Fedora||OS Version||22|
|Target Version||2.6.0||Fixed in Version|
|Summary||0000737: Suggestions for improved trim behaviour|
|Description||The 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
"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 Reproduce||I tested with a directory with sequential images. I overlayed the frame numbers|
in the images for easier testing.
|Tags||No tags attached.|
|Estimated work required||Small|
||Thanks for the suggestions. They are implemented in b6a281b4ba1d5e2b91ae3d54e073ee88308f61b6 and 294704d07de1fd6981362d85a26e4a83a6ef08fa which will be in 2.5.1.|
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!)
- 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)
||Thanks for testing things. Your further points should be ok in 8cc825a798d9a457b89f968a57d3b6a16f6cedfe (2.5.2).|
|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|