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/ ***************************************************************
