[Kdenlive-devel] GUI

[Rolf Dubitzky]

On Friday 03 January 2003 11:05 am, Jason Wood wrote:
> The buffering should definitely happen on Kdenlive's side of the
> communication. However, the main optimisation that I want to try first is
> to only send the updated parts of the scenelist - this adds another command
> to VEML, so I want to wait until we have released 0.1 source pacakges
> first.

I would really prefere it the other way round. The fact, that kden is sending 
the complete scenelist many time is really keeping me from debugging the 
building of the render-tree. Updating parts of the scenelist will be 
difficult for my part. Updating parts of the tree is very complicated. PIAVE 
only knows about unary- and binary-nodes. The scenelist is at present 
represented by a tree of binary-nodes. To be able to update a part of the 
list, I will have to implement complicated tree operations, or introduce 
sequential multi-nodes.
The latter makes more sense , but both solutions will take a while to test and 
debug.

Can't you just set some kind of flag somewhere that the scenelist was 
modified, and when doing a 'seek' check that flag? If it's set, then send the 
scenelist before the seek.

That would also fix the bug, that the scenelist is not send when you load a 
new file. Just set the 'modified' flag when loading a file ...

> Hmm, there is no buffer implemented unless it exists in QT's code. I'll
> look into it.

Very strange.. the scrlling is really diffrent. Sometimes the slider jumps 
around over _many_ pixels. Can you confirm that behaviour?

> > Where is that razor tool you mentioned?
>
> It should be available on the Timeline menu, and on the toolbar. If you
> cannot see it, you need to ./configure --prefix=kdeinstalldir and do a
> "make install" to put the kdenliveui.rc file into the correct place.

I did 'make install'  , but without a configured prefix. The default prefix 
seems to be '/usr/local/kde' which is ok for me. Do I need to set a different 
prefix? If so, which one? I don't want to mix my development stuff with the 
system installation (actually on some of the systems I am testing, I am not 
even allowed to do that).

> The spacer tool is also partially implemented - it will select all clips
> which are to the right of where you click, and if you hold down shift, it
> will also select clips which are at the point where you click. Currently,
> you cannot move them though.

Great.

> If you tell me what you would like me to send for "black", it should take
> about three lines of code to implement.

How about (I skipped duration, etc.. )

<scene>
    <stillcolor rgbcolor="#000000" />
</scene>

or  <stillcolor yuvcolor="#000000" />

for an image

<scene>
    <stillimage file="/path/to/some/file.png" />
</scene>


> > 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.
>
> The main reason would be if you are editing your project non-linearly. For
> instance, let's say that I start editing somehwere in the middle of the
> project, I would not bother lining it up with the 0:00.00 mark. When I have
> finished with the middle section, I will just move it to the right on the
> timeline to get it out of the way, and then start work on the title
> sequence.
[...snip...]
> One feature that I do need to add though, is a "snap to 00:00.00" feature.

yes, I already wrote a lengthy reply, but after reading the last sentence, I 
just deleted it. The combination of 'spacer'-tool and 'snap to 0.00' would do 
exactly what I want.


Cheers,
Rolf

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