[Kdenlive-devel] Release and future...

[Till Theato]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/03/2011 01:06 AM, jb wrote:
> On Saturday 03 September 2011 00:44:46 Till Theato wrote:
> 
>>> 1) Change the effect XML depending on the filter version
>>> 
>>> I did some test and managed to have a working implementation
>>> that will bring different parameters depending on the filter
>>> version, see my last commit: 
>>> http://kdenlive.svn.sourceforge.net/viewvc/kdenlive?view=revision&revisi
>>>
>>> 
on=5855
>> Is
>> 
>> it correct that only one file was committed?
> 
> Yes. It is possible to put several effects description in just one
> file if we put the effects in a <group> tag.
> 
>> 
>>> 2) upgrade project files using older version of the filter
>>> 
>>> Since MLT now stores the frei0r filter version in the xml data,
>>> it should be pretty straightforward. Till, are you taking care
>>> of it? I will have some time between the 5th an the 7th of
>>> September in case some work is required on that side.
>> 
>> Sorry for the delay, I am fighting with QtScript for a week now
>> (with little spare time). The result unfortunately is a lot of
>> redundancy across the XML files and overall ugliness. As you can
>> see in the attached file: Way to much code for only a single
>> file... The adopt function could be replaced by what you
>> introduced in your latest commit or by what Dan proposed: Do the
>> same thing you implemented but on parameter level (-> less
>> duplication).
> 
> Currently, it seems easier to me to check it at the effect level.
> Having it at the parameter level could bring some complicated stuff
> (imagine that we have 3 versions of a filter, each having different
> minimums, maximums, parameters appearing or removed... That would
> in the end result in a very complicated xml.
> 
> In my version, we simple put one xml copy for each version of the
> filter, and Kdenlive will only load the correct version.

The attached patch is what i came up with. As I already said I will
drop the adopt function (and therefore the changes in initeffects.cpp)
again. With your system where should the routines part be placed?
Since it is needed in trackview it has to be inside <effect>. However
there will be at least two <effect> elements whenever a routine is needed.
Another problem is see with your approach is the amount of
duplication, since some XMl files are not that small (e.g. SOP/Sat).

Any ideas to avoid duplication in the update function (across multiple
effects)?


> 
> 
>> Regarding the update thing I don't know.... Levels is a rather
>> easy example but on other effects we can't just multiply the
>> whole thing by a factor since we also have to consider keyframes.
>> Rather easy however with the update function concept. Anyone any
>> ideas on how to do it with less code?
> 
>> The adopt function is fully integrated in Kdenlive and works, but
>> is probably to be removed again. The result of the update
>> function is not yet replacing the original effect in the project.
>> I will try to finish it this weekend. Well that is unless someone
>> comes up with a better idea.
>> 
>> For the update thing to work a MLT release would be required,
>> too. @Dan?
> 
> Oh, you mean because the frei0r version is new in MLT... right I
> didn't think about it...
> 
>>> Once both steps have been taken for the filters that will be 
>>> modified in frei0r, I will prepare the release.
>> 
>> What about that 10 tracks bug?
> 
> That's an MLT issue, I have not investigated more.
> 
> regards jb
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk5iqa0ACgkQzwEyz7QP6nSE7wCff81lR/DuZyTUEJ3cJsTlVGZn
CjYAnj+FjecLcrdPOtvXkvNfkXVjwluY
=4Yya
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: effect-adoptupdate.patch
Type: text/x-patch
Size: 9582 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20110904/8a4793d3/attachment.patch>