[Kdenlive-devel] GUI

[Rolf Dubitzky]

On Monday 30 December 2002 08:49 pm, Jason Wood wrote:
> > > This all needs discussion, I am a little unsure as to the best way to
> > > handle the monitor from this point on. The way I see it, there are two
> > > possibilities
> > >
> > > 1. Have the monitor have two modes. In one mode, it displays the entire
> > > timeline for previewing purposes. IN the other mode, it only shows the
> > > currently selected clip, which can be trimmed and dragged to the
> > > timeline.
> > >
> > > 2. Have a separate monitor for each mode.
> > >
> > > Which do people prefer? Are there any other options?
> >
> > How about only a single mode in which the monitor window displays
> > whatever timeinterval is selected in the timeline.
> > Here is how MovieDV works:
> >  There are two different kinds of 'Selections' in the timeline. First,
> > you can select a clip, or mor clips and drag them around, (that's what
> > kdenlive can do alrready). Second, you can select 'time intervals' by
> > clicking/draging in the ruler (not the timeline opbjects). If you then
> > press 'play', you'll get a preview of the interval you have selected. If
> > there is an eaay way (context-menu/button) to 'Select All' in the
> > timeline ruler, then you can watch the whole thing.
>
> When you preview an interval, can you manipulate it in any way? The main
> interface feature I am concerned about here is the setting of in/out points
> on a clip that is to be inserted into the timeline. In Premier, this is
> handled by dragging it to a monitor, setting the in/out and dragging it to
> the timeline. How does it work in MovieDV?

Pretty similar. The difference is that there are mutliple viewers/monitors in 
MoviDV where you can do similar editing operations, which is very confusing.


I am implementing the parsing of the scenelist. It's a little more work than I 
thought, but I'll get there. One thing that makes problems is that kdenlive 
sends the scelist mcuh too often. when dragging a clip in the timeline I get 
a lot of traffic, not that this is only slowing down the system, but it also 
overstrains the renderer. I could buffer all the sent scenelists as ascii, 
and only parse them if a <seek>-command is sent, but I think that the 
renderer is the wrong place, we should be economic with recources.

In the last kdenlive version I have the feeling that the scrolling through the 
video is more stuttering. The renderer sees very often, that many <seek> 
commands are sent in a single message. Did you introduce some kind of buffer 
or anything? Apart from the fact, that sending multiple <seek> in one message 
does not make much sense anyway (they'll just get dropped) I have the 
impression that the scrolling is not as smooth as it used to to be. 

Where is that razor tool you mentioned?

Another thing we need to discuss is, how to handle gaps. kdenlive allows for 
gaps between clips, and especially because the first clip does not snap to 
0.00 the is almost always a gap between 0.00 and the start of the first clip.
We have two options: a) the renderer just displays "something" for gaps. This 
"something" could be 'black' a test frame and/or be userdefined.
b) kdenlive does allow for gaps in the timeline, but does _not_ send gaps to 
the renderer but fills them up a still image element. This way the GUI is 
always in control over what gets displayed in gaps.

Do you think it makes sense to have the first clip _not_ start at 0.00? If 
there is no major reason to not do so, I think it would make sense to define 
0.00 as the starting point of the first clip. If the user wants a few seconds 
of black before the first clip starts, he can still insert it explicitly.

Cheers,
Rolf

***************************************************************
 Rolf Dubitzky  
 e-mail: Rolf.Dubitzky at Physik.TU-Dresden.de
 s-mail see http://hep.phy.tu-dresden.de/~dubitzky/
***************************************************************