[Kdenlive-devel] 1. Refactoring Update

[Till Theato]

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