kicad-developers team mailing list archive
Mailing list archive
Re: KICAD_PLUGIN for libraries/components (pcbnew)
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,
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.