[Kdenlive-devel] Bin columns

John T. Mertz thatonefilmguy at gmail.com
Wed Mar 31 20:39:30 UTC 2010


Ah hah! I found the culprit. :oD

In mainwindow.cpp, line 1429 (might be slightly off of the svn head):

m_projectList->setHeaderInfo(state);

This restores the old saved state of the headers, so any new header
options set in projectlist.cpp will never take effect.

Commenting out this line made the columns moveable; however, then it
does not restore the order of the columns at startup.

-JTM

On 3/31/10, John T. Mertz <thatonefilmguy at gmail.com> wrote:
> Hi Alberto,
>
> As I said in the other (wrong) thread, I tried your patch and it is
> not working for me either.
>
> Thanks,
> -JTM
>
> On Wed, Mar 31, 2010 at 8:03 AM, John T. Mertz <thatonefilmguy at gmail.com>
> wrote:
>> On Wed, Mar 31, 2010 at 7:10 AM, Alberto Villa <avilla at freebsd.org>
>> wrote:
>>>
>>> On Wednesday 31 March 2010 00:00:05 John T. Mertz wrote:
>>> > I tried dolphin as you suggested but was only able to turn columns
>>> > on/off, but I could not reorder them.
>>>
>>> that's strange, i'm able to do that
>>
>> Maybe it is the version I am running?  I only have dolphin installed
>> because I installed KDE on top of Ubuntu 9.10, which installed Dolphin
>> with it.  But it's no matter since you know what I'm talking about.
>>
>>>
>>> > For example, the default display might have these columns:
>>> > Clip Name | IN | OUT | Start | End | Duration | Description
>>> >
>>> > But I might rearrange it to display in this order:
>>> > Clip Name | Description | Duration | Start | End | IN | OUT
>>>
>>> what do you mean by IN and OUT? project clips in kdenlive don't have in
>>> and
>>> out points... each item represents a whole clip
>>
>> 'IN' is called "Set Zone Start" in kdenlive
>> 'OUT' is "Set Zone End" in kdenlive
>>
>> IN/OUT is standard terminology used by all NLE software.  As a side
>> note, kdenlive should really change from using "Zone Start/End" to the
>> widely used standard "IN" and "OUT".
>>
>> The IN/OUT points on each clip are saved after you set them.  Having
>> the IN/OUT displayed in columns in the bin is useful because you can
>> see where IN/OUT points are set on a clip (if they are set at all)
>> without loading it into the clip monitor.
>>
>>> the same for Start and End: what are they?
>>> this is just curiosity, it doesn't impact on this matter
>>>
>>
>> Pretty much all video cameras embed a timecode track along with the
>> video track.  'Start' and 'End' are the Start timecode and End
>> timecode of the clip as defined by the clip's timecode track.  I don't
>> know if clip timecode is made available by any video playback/editing
>> applications in Linux. I can't say I've ever seen a proper
>> representation of timecode when playing any type of video format on
>> linux.
>>
>> The start/end timecode provides the editor with a linear sequence of
>> shots when editing, since the timecode for each clip progresses in a
>> linear fashion.  When each clip is recorded, its starting timecode
>> value is (typically) the frame after the End Timecode value of the
>> previous clip.  Take, for example, a tape where the Start timecode of
>> the tape is set to 01:00:00:00.  Let's say you shoot three clips on
>> the tape of varying durations.  The timecode for each clip would be
>> something like this:
>>
>> Clip1  StartTC 01:00:00:00 -> EndTC 01:01:34:23
>> Clip2  StartTC 01:01:34:24 -> EndTC 01:05:26:12
>> Clip3  StartTC 01:05:26:13 -> End TC 01:11:56:08
>>
>> As you can see, it is easy to tell the order of the clips because the
>> Start timecode increases with each new clip.
>>
>> A lot of professional videographers also use timecode to differentiate
>> between different tapes.  For example, they will set the camera to
>> start recording on tape 1 with the timecode of 01:00:00:00, then tape
>> 2 will start at 02:00:00:00, then tape 3 at 03:00:00:00 and so on.
>> When they go to editing and capture all their media, they can easily
>> determine which tape each clip came from based on the timecode.
>>
>> Start Timecode is usually retrieved from the timecode track of the
>> captured clip.
>> End Timecode, on the other hand, is usually calculated as the Start
>> Timecode + Duration of the clip.  This is because it is possible for
>> clips to sometimes contain timecode breaks (for example, in one frame
>> the timecode is 01:33:24:13, then the next frame following it the
>> timecode might jump to 05:23:14:02).  So most editing applications do
>> not bother with displaying timecode breaks; rather, they just ignore
>> them and calculate everything based on the Start TC.  FYI.
>>
>> There are other uses for timecode as well, but I won't get into them
>> all here.  In any case, it is an important feature that kdenlive
>> should (eventually) support if it wants to gain any traction in the
>> prosumer video editing market.  I have no idea how much metadata from
>> captured clips is made available to the application, if any.
>>
>>> > Then, usually the user can save a custom Bin View so that depending on
>>> > what they are working on, they can load different bin views which
>>> > would reload the column display and order that was saved (although a
>>> > single, customizable bin view would be an excellent start).
>>>
>>> ...and that could be made a little more powerful by allowing also other
>>> things, e.g. icons size, icon view vs. detailed view...
>>>
>>
>> Yes! I fully agree :o)  Icon view, Icon size, detailed view is all
>> important!  Depending on your editing style or if you are looking for
>> a certain clip, different views serve different purposes.
>>
>>> actually, i don't dislike this layout, it's very compact. but, following
>>> my
>>> suggestion above, why not making different layouts available?
>>>
>>> anyway, could you please test the attached patch? it should unlock the
>>> columns (and adding a voice to the header popup menu, but that's not the
>>> point). it appears that i'm not able to make it work here, but according
>>> to
>>> the documentation (i've spent some time on the qt website and through
>>> the
>>> kdenlive source) and considering that it wouldn't be the first time that
>>> something builds wrongly on freebsd - and, perhaps, ccache it's doing its
>>> own,
>>> too - this doesn't work for me (while a stupid 4-lines examples does)
>>> --
>>
>> I will give it a try when I have a chance.  Thanks!
>> -JTM
>>
>

-- 
Sent from my mobile device




More information about the Kdenlive mailing list