On 04/07/2012 11:12 AM, Miguel Angel Ajo Pelayo wrote: > > I recently talked about this (in a couple of emails), and Dick > confirmed it was > on the plans, > I exactly mean moving the pcbnew/librairi.cpp into the plugin system. > > My questions are: > > 1) Could I be the one addressing this? > > 2) Is there any design about that? or should I go with the design first? > > 3) If 1 is yes, should I open a branch, work on this, and we merge it as > it's done? > > > Greetings to everybody,
Mike If you want to propose some virtual functions, simply Doxygen commented function prototypes, that can be added to the the PLUGIN API, this will give us a chance to see your C++ design skills at work. Please just start with the function prototypes, Doxygen commented, no actual code yet. There can be private functions also, but the public ones need to handle: a) existing legacy libraries using footprint/module load save code already in LEGACY_PLUGIN so we can automatically scale these legacy modules to nanometers. b) new s-expression libraries where each footprint is simply a separate file, so the "library" parameter to any API function is essentially a directory, whereas for LEGACY_PLUGIN it was a file. See if this is do-able from a design standpoint. My thinking was to get this work into the testing tree. Then ask you to merge it into your scripting tree. I was planning on using your tree to do the actual conversion of all the footprint libraries over to new s-expression format, simply by looping through footprint by footprint, using LEGACY_PLUGIN to load, and KICAD_PLUGIN to save the footprints. If you cannot get to this conceptual contribution within a week, or have other interests now, such as HTTP_LIB_SOURCE, that is understandable, just say so. Thanks, Dick _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
