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

[Jason Wood]

On Thursday 24 Oct 2002 8:45 am, Rolf Dubitzky wrote:
> > 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! ;-)

:-)

Yes you could and should extend at least my GUI, but what I mean is that it is 
not going to make the computer crash'n'burn if the GUI doesn't know about 
some advanced feature in the engine.

For instance, someone might make as proof-of-concept a simple GUI which 
emulates a tape-to-tape linear editing machine. The GUI would be quite within 
it's right to ignore the fact that the engine has transitions, etc.

> > 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 ...

That would be difficult, as different GUI's might view the editing process in 
different ways, and will likely save data in different formats.

For instance, my GUI will use a fairly standard timeline approach to editing, 
and it's project format was designed accordingly. The project saves video 
clips by saying "this clip starts at time x on track y, and continues for a 
duration of z seconds with efffects a, b and c applied".

> > 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.

I have not really been expecting people to edit the cutting list directly , so 
I was working on the principle that it is easy to find an XML parser around 
these days to automatically shove everything into a tree data structure for 
you.

On the other hand, I am seeing that there could be merits in having a command 
line interface to the engine, if for no other reason than for teaching how 
the interface works.

>
> > 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 ;-)

What kind of things are you talking about here? Is it a case of transitions, 
effects, etc?

> 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.

I agree, but don't feel that you have to change to QT just to match the GUI - 
if a Gnome GUI comes along and used your engine, they will still have 
dependencies on both toolkits.
>
> > 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.

That's interesting. Are their any web links to it? I'm not going to switch 
toolkits again :-) but I would be interested to see how he does signals and 
slots.

> > :-) 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.

I will start putting together a more complete document on how I think the 
interface would work, as there a number of ideas that need to be included.

Chers,
Jason

-- 
Jason Wood
Homepage : www.uchian.pwp.blueyonder.co.uk