kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

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