-----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 ;) regards Till -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAk+vsP8ACgkQzwEyz7QP6nSdxQCgijkxHbGvSiNSycjq9Bhnqg45 x6YAn3danTE2E19n3vWkY7bwxfrADAmx =fjAI -----END PGP SIGNATURE-----
