Thanks for your answer, The solution you propose is not really good imho. Because, from a dev point of view this mean that each time you update a module, you would have to ask you how to handle this in lightroom code. And as you know, final design need lot of try, which doesn't suffer any delay ;) ... And that didn't solve the modular problem.
parafin propose a solution : duplicating struct and iop version in your header, instead of including *.h That way, you can create safe history stacks and if the iop version has been updated, the iop legacy_params fct will update params. boucman propose to add some assert statements... Thanks Aldric PS : and sorry for my English... Le 21/01/2013 21:26, Pascal Obry a écrit : > Aldric, > >> Sadly I have no idea how to avoid this (my coding are too poor, sorry) > I have also no solution. But to me this is not a big problem... Well, > not the only big problem as when the new version of Lightroom will be > out an update of the import support will also be required. > > For the lightroom.c in Dt, feel free to ask me to fix when a change is > done in an iop. I'll do the maintenance of this part. Also not a big > problem, as we will get a nice message if the iop versions does not > match. Also, my point of view is that this part is not as important as > core Dt, so it can be broken on master from time to time, I'll do the > maintenance. > > Does that sounds fine to you? > > Pascal. > ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 _______________________________________________ darktable-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/darktable-devel
