|Anonymous | Login | Signup for a new account||2014-09-20 00:35 CEST|
|My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000362||Kdenlive||User Interface||public||2008-11-18 12:59||2010-11-15 13:54|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Product Version||Recent git|
|Target Version||Fixed in Version||0.7.1|
|Summary||0000362: weird/wrong behaviour when moving 'crop from start' in a layout with 3 clips e.g.|
|Description||The right edge of the second clip slips over, and sometimes under, the start of the third clip when moving 'crop from start' (the left edge) of the second clip to the left.|
Also undo is broken after that action.
|Steps To Reproduce||- Make a new project.|
- Put 3 regions/parts (not the whole clips) of 3 clips on the timeline, one after another with no gaps.
- Move the right edge of the second clip to the left.
- do 'ctrl + z'.
|Additional Information||In general I really like this behaviour, when moving the left edge of the third clip to the left, which enlarge this clip.|
So, it would be nice if this would work also with clips in between, like the example above, where the following clips will be moved then without creating gaps.
But maybe this should be initiated by modifier keys like:
- shift + left/right == change the length of the clip AND project.
- ctrl + left/right == change the length of the clip but NOT of the project; this means that the adjacent clip will be changed in length.
- alt + left/right == just move the I/O region (the frames) but not the clips position on the timeline.
|Tags||No tags attached.|
|Attached Files|| kbw.gdb.output.CEH16398 [^] (24,548 bytes) 2008-11-19 20:46|
capture0008.ogv [^] (3,036,296 bytes) 2008-11-30 18:02
I get a crash for 2714 when I try to do the steps to reproduce (attaching backtrace)
Is that the same you get.
And, is this really two bugs: no undo for that operation, and that you want to be able to move the remaining track when you uncrop a middle clip?
Reminder sent to: reinhard
This issue is marked as fixed in the latest svn revision (2736). Could you update your Kdenlive (run the KBW again if that's how you installed) and let us know if this problem has been fixed for you?
Yes I still use kbw (kdenlive svn 2740) and in general the initial problem is fixed, but I just wondering why I can't move the left edges of clip 1 + 2...
Another problem is when moving the right edge of clip 1 or 2 a bit too much to the right (upon the clip on the right side). In this case a black frame will created, because the right edge jumps one frame to the left.
And also yes to 'want to be able to move the remaining track when you uncrop a middle clip', but this may be changed into a feature request for now.
Actually the focus should be on providing basic editing functionality...
I'm having trouble understanding your description of this problem. As far as I can see, all track edges are able to be moved left or right wherever there is extra footage. A couple of things would help:
1. Limiting each bug report to only 1 issue / wish.
2. Describing how you create this problem step-by-step (see the "Steps to Reproduce" part of http://en.wikibooks.org/wiki/Kdenlive/Reporting_bugs [^] for an example)
3. An image or video screengrab that shows the problem.
4. Explaining what you mean by clip 1+2. Do you mean a specific clip on track#1 and another specific clip on track#2, or are you referring to three segments on one track, the first being #1, the second being#2 and the third being 0000003?
The clearer the bug description, the faster we can get it fixed. :)
(a confused) Cinephiliac
I'm sorry confusing you, but I'm not a native english speaker, but I try my best ;)
The new problem seems to be some kind of a follow up of the initial issue, so I thought I simply put it into the same thread, but the next time I will start a new issue.
Since I answered to this issue I still used the same 'layout' as described above in "Steps to Reproduce".
This means - still 3 segments in one track.
I've tried to upload a screengrab session, but I failed due to limited upload bandwith... but I will try again.
Yes, 3 sequenced segments in one track.
And the left edge of segment 1 and 2 can't be moved.
And e.g. the right edge of the first segment will be shortened by 1 frame when you drag this right edge a bit too much too the right (rev. 2740).
I will try now to upload a screengrab... ;)
svn 2736 stops the crash. There are still issues with the clip resizing though. We need a concise description of the current, and intended behaviour. Unfortunately I am not able to create it right now.
There are some weirdness in some of this, and also a feature request.
ok, you are right - we should isolate the real issue here.
This seems to be the changing of 'crop from start:' which seems to work only for the last clip in timeline (still assuming 3, or more, clips in a row).
So, actually (rev. 2809), 'crop from start:' can't be changed (by moving the left edge to the right side) by any of the previous clips to the left.
At least personally I think it should be possible to change 'crop from start:' for ANY clip in the timeline... ;)
Some changes to this behaviour has been commited in svn rev. 2816.
I do not understand what this issue is about any longer, but I have made some observations myself. I find two issues that I believe are flawed:
a) Moving the right edge of a clip will *sometimes* move it left.
b) Moving the left edge of a clip, will allow it to grow right, if there is room
I think a) is a bug. b) is highly confusing and potentially damaging.
Since I believe a) to be a bug, I am acknowledging.
Steps to reproduce:
- start kdenlive
- add a clip to the timeline
- cut into three ([a][b][c]).
- zoom in on the ab cut
- gently drag the green triangle of a to the right. Observe how the right end of a may move left(!)
- now, drag the right end of b a little to the left, getting something like: [a][b][space][c]
- drag the left side of b to the left, observe how b grows to the right.
I am unsure what the intended behaviour should be? But these issues confuses me...
Svn commit 2852 (part of 0.7.1) fixes issue b) from comment 1951.
a) is still present, when zoomed into the cut, but appears to not be present when not zoomed in.
What to do? Is this little flaw acceptable?
|a) was not fixed because I could not reproduce it. It needs to be fixed, so I will look at it.|
|2008-11-18 12:59||reinhard||New Issue|
|2008-11-19 20:43||madsdyd||Note Added: 0001256|
|2008-11-19 20:43||madsdyd||Status||new => feedback|
|2008-11-19 20:46||madsdyd||File Added: kbw.gdb.output.CEH16398|
|2008-11-27 02:08||cinephiliac||Note Added: 0001438|
|2008-11-28 00:50||reinhard||Note Added: 0001450|
|2008-11-28 22:08||cinephiliac||Note Added: 0001454|
|2008-11-30 17:49||reinhard||Note Added: 0001461|
|2008-11-30 18:02||reinhard||File Added: capture0008.ogv|
|2008-11-30 22:08||madsdyd||Note Added: 0001468|
|2008-12-21 17:38||reinhard||Note Added: 0001869|
|2008-12-28 23:52||madsdyd||Note Added: 0001951|
|2008-12-28 23:52||madsdyd||Status||feedback => acknowledged|
|2008-12-30 00:25||madsdyd||Note Added: 0001972|
|2008-12-30 18:06||administrator||Note Added: 0001979|
|2010-11-15 13:53||ttill||Build/Install Method||=> (select)|
|2010-11-15 13:53||ttill||Assigned To||=> j-b-m|
|2010-11-15 13:53||ttill||Status||acknowledged => resolved|
|2010-11-15 13:53||ttill||Resolution||open => fixed|
|2010-11-15 13:53||ttill||Fixed in Version||=> 0.7.4|
|2010-11-15 13:54||ttill||Status||resolved => closed|
|2010-11-15 13:54||ttill||Fixed in Version||0.7.4 => 0.7.1|
|Copyright © 2000 - 2014 MantisBT Team|