On 09/06/2011 09:53 AM, jb wrote: > On 09/05/2011 04:48 PM, Till Theato wrote: >>>> 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? > (...) > I have to think more about this effect upgrade stuff. Should we support > only upgrading or also downgrading? Things might become complicated if > an effect has 4 different versions and we want to allow every possible > change (12 possibilites if I count correctly...) >
So after a good coffee, here is my proposal: 1 - Move the upgrade code from trackview to documentvalidator (which is a more logical place for updates to the document) 2 - Put the upgrade code in a different xml file, called like the kdenlive_id of the effect, for example frei0r.balanc0r upgrade code could be in a file called frei0rbalanc0r.upgrade 3 - In documentvalidator, we load all upgrade xml in a QMap <QString, QDomElement> using the file name as key. 4 - In documentvalidator, we parse all effects and if we have a version under the current one and the effect has an entry in the previously created list, we trigger the update. What do you think about that? regards jb ------------------------------------------------------------------------------ Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev _______________________________________________ Kdenlive-devel mailing list Kdenlive-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kdenlive-devel
