Le 16/01/2013 22:15, Simon Spannagel a écrit : > Well, as far as I understand the design concept at this edge of the code > (and this is not too much actually) one of the principles is keeping the > modules (i.e. IOPs) completely separated from the core components of > darktable. The core itself doesn't know about them at all. This features > some nice side effects in maintainability and so on - your current > implementation breaks this barrier and introduces exactly that clutter > we wanted to avoid: you have to hack the core as soon as you change a > module...
To my defense I have copied some other part. For some of the iop there was headers exposing the internal of the parameters for example. So I have done the same for some where it was missing. What would be the other solution? Adding routines in the iop to create a struct (opaque type dt_iop_params_t) based on the parameters? struct dt_iop_params_t *create (float cx, cy, cw, ch...); Would that do? -- Pascal Obry / Magny Les Hameaux (78) The best way to travel is by means of imagination http://v2p.fr.eu.org http://www.obry.net gpg --keyserver keys.gnupg.net --recv-key F949BD3B ------------------------------------------------------------------------------ Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 _______________________________________________ darktable-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/darktable-devel
