[Kdenlive-devel] moved here from kde-multimedia (was Re: Multimedia Frameworks)

[Rolf Dubitzky]

On Thursday 24 October 2002 01:36 am, Jason Wood wrote:
> Ok, you can't have a 100% seperation, but the important part of the
> interface - playing, recording, timeline, project management, etc. can be
> seperated. Essentially, the engine needs only to be able to display video
> itself, which is a hack for speed reasons over the "perfect" solution (of
> chucking the data to the GUI for it to display)
>
> I am not convinced that we cannot create a communication layer that is
> implementation independant - I see the need for the GUI to recognise the
> limitations of the engine, but that, I believe, can be handled by a
> suitably comprehensive "ok, tell me what you can do" type of command, that
> returns a list of everything that the engine is capable of.

I think we agree 100% in what the goal is. Maybe I am just a little too 
pessimistic :-) Let's try, and see what is possible.

> If I look at the engine recognising the limitations of the GUI - that's not
> essential. If the engine is capable of something that the GUI can't do, the
> GUI will simply never ask the engine to do it.

Hey! Nono! Then I'll simply extend the GUI to make it capable! ;-)

> I am not so sure that it is not possible to come up with a generic GUI.
> Christian and I put together a specification on how to transfer data from
> the GUI part of the program to the engine, which essentially works as a
> tree-based view. This is not how my GUI works however; it needs to
> translate the data to this view model.

That sounds good.

> In the same way, I am wondering how much translation would be required to
> reach your view model?

Not too much, I guess. It's a complicated scheme. Exporting a GUI-usable, 
serialized timeline could even be part of the engine ...

> If you want to look at the last cutting list specification we wrote - i.e
> the data we should send to the engine to tell it what we want to achieve -
> then you can find it on this page :
>
> http://www.uchian.pwp.blueyonder.co.uk/kdenlive_documentation.html

Very nice I'll look at it.

> We have been discussing converting the overall format to XML  to make it
> easier to parse (by using a generic XML parser such as libxml).

My engine can already be saved/stored as HTML... I hate the look of the 
output.. well.. but it works. It looks very similar to your example, but if 
you have a just mildly complex scene it gets completely unreadable for the 
human eye. In the beginning I actually though of the possibility to have an 
alternative view as a ascii file, similar to html editors where yo ca switch 
between view, ar the moon modeller, where you can switch between text and 3D 
view view for you 3d scene. I have to come up with a much nicer HTML foramet 
for the scene before that is an option.

> How easy would it be to add a translation layer that could turn this into
> something usable by your engine?

Easy. But my engine can do _much_ more already. And of course I don't want to 
get the features burried because the XML can't handle them ;-)
It' can't actually handle text yet, because I didn't know which toolkit I'll 
use in the end. I already implemented some stuff with freetype, but if I 
switch from GNOME stuff (gdk-pixbuf/libxml2) to Qt, I will change that, It is 
stupid to depend on both toolkits.

> Better to ask Christian on the state of his engine, we often discuss the
> interface between how the GUI and engine/cutter should interact, but on a
> coding level, we have so far worked completely independantly.

I see.

> From my point of view, I would love to create a generic linux video editing
> framework that is independant of GUI and Engine. So if your friend is
> interested in, say, a Gnome, or pure GTK GUI, then that is totally fine by
> me.

His major is GUI-design and he has actually his own GUI Toolkit. It's quite 
nice, and from a design point of view, I like it much more than Qt, because 
it incorporates the qood things from Qt and a number of other Kits, but does 
not need a moc. Signals and slots are even more independent and the 
construction is even more intuitive than Qt. It is not half as complete as Qt 
though.

> :-) The important thing is interoperability between various cutters/engines
> and GUI's.

Agreed. I will look into you interface description and propose to look at it 
to my friend. For my part, I like the idea of independency beween GUI/engine 
but just was not very convinced that it will actually work anymore.

Cheers,
Rolf

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