On 13.05.2012 15:02, Till Theato wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hey guys, > > so finally here it is. > I've been working on a new effect system and I think it is now in a > state were I can write about it a bit, at least to the fellow > developers, since there isn't much to see yet. Only the basic > structures are done, but they should allow to add the old > functionality quickly. > > The new initEffects, has turned into a much lighter EffectRepository. > Here we look for available filters and Kdenlive XML effect > descriptions. MLT metadata is now only used when no XML effect > description is present so there is no need anymore to blacklist those > effects. The metadata or the XML is then handled by object of the > EffectDescription class. Here information like name, kdenlive id, > tag/mlt name, author, description are extracted and stored. The > parameter elements or MLT properties also have their own objects. All > information about them is processed and stored in classes inheriting > from AbstractEffectDescription. Each parameter type has its own class > so there is for example DoubleParameterDescription, but more about > parameters later on. > So after the initial loading process we don't need any XML DOM > anymore, which means that there is no need for functions spreading > across the whole code to take care of it. > > Now, the actual use of effects. Since there are multiple items that > can have effects, currently tracks and clips, there is a class called > EffectDevice which takes care of handling anything effects related. It > has direct access to the MLT service the effects should work on, so it > is responsible for inserting and deleting the effects' filters there. > When an effect should be added its description object is told to > create it. This way no information about it has to be passed around. > The effect object creates an MLT filter and will then handle all > changes which should happen to it. By keeping a pointer to the effect > description object in the repository it is not necessary to duplicate > any information like name, description, ... . The parameters are also > created by their description objects so no knowledge is required about > their type. > All these different levels (from device down to parameter) have > currently 3 different views: the traditional effectstack, now called > properties view (not fix though yet), the timeline view, to draw for > example effect names or keyframes and the monitor view for on monitor > editing. > So when this is all finished we should have a completely > self-contained effect system with very short connections and one that > is also easy to enhance and enlarge. > > That was the trigger for some words on the parameter implementation ;). > Parameters are where most specialization is required. They are > therefore now kept as plugins. A .desktop file tells the repository > which types the plugin handles but everything else is plugin internal, > from parameter description to the actual implementation to the > different views. > > This however required the introduction of a Kdenlive library since the > parameters are not based on mere interfaces but on abstract base > classes and since they also need to have access to some widgets for > example. > The plan is to expand this library during the refactoring so that in > the end (given that I'm fast enough ;)) almost everything is either in > a plugin or in the library to be accessible by plugins. > > As a next stept I want to port some more functionality to the new > effect system and then start working on the timeline, which should be > quite similar though much more complex. > > > Let me know what you think of all this, whether I missed something > completely, or whatever ;)
Inmidst of the bazillion of homework and projects and soon exam preparations I finally found time to read this. (The code not yet.) Sounds all very well-structured and clean, looking forward to working with it if I ever have to. Since I cannot give any helpful comments, I just say: Thank you :) Simon
