← Back to team overview

kicad-developers team mailing list archive

Re: KICAD_PLUGIN for libraries/components (pcbnew)


This is a first approach.

It's what I understood from your last email, my idea was more complicated.


1)  Added to new plugin types:
+        LEGACY_LIBRARY,                 //< Legacy Pcbnew library file
+        KICAD_LIBRARY,                  //< S-expression based library

2)  Added a new load method to io_mgr.h (plugin is the same without the

+    static MODULE* LoadModule( PCB_FILE_T aFileType,
+                                const wxString& aLibraryPath,
+                                wxString& aModuleName,
+                                BOARD* aAppendToBoard = NULL,
+                                PROPERTIES* aProperties = NULL);

I kept appendToBoard (makes sense), and properties (in the future it could
be loading options for the plugin, like http credentials, or whatever).

librarypath could be either: directory (new format), file (other formats),
http uris (future?)

3) Added SaveModule (io_mgr + plugin, as "2")

+     static void SaveModule( PCB_FILE_T aFileType, const wxString&
+                              MODULE* aModule, PROPERTIES* aProperties =

I think it needs no explanation

4) Added ListModules  method (io_mgr + plugin, as "2,3"):

+    static wxArrayString ListModules ( PCB_FILE_T aFileType,
+                                       const wxString& aLibraryPath,
+                                       PROPERTIES* aProperties = NULL);

that will return an array of names with all the available modules in that


    a)  This design would be simple, and must work
    a.1) The doxygen doc headers are compiled and checked.

    b)  Some plugins would only know how to open PCB files, some plugins
will only open MODULES/libraries
         b.1) Could make sense some interface to check the plugin
capabilities or make a enum type for modules/libraries instead.
    c)  There is the case of opening/saving single componente files
(.cmp?), that would be almost the same plugin.

Future ideas (that I might want to add for py-scripting) -out of scope
right now-:
     e)  Dynamic plugin registration, then a python PLUGIN could get itself
registered on IO_MGR to read/write formats: that would lead to faster
format importer/exporters development.

2012/4/12 Miguel Angel Ajo Pelayo <miguelangel@xxxxxxx>

> 2012/4/12 Dick Hollenbeck <dick@xxxxxxxxxxx>
>> The changes to PLUGIN should be "additional functions for MODULEs".  I
>> like what we have
>> for BOARDs now.
> Ok, I thought about this idea at first, but tried to make it too abstract
> ;), it's simpler this way.
>> The new work entails abstracting the *loading* and *saving* of a MODULE
>> from/to a "MODULE
>> library" (aka MODULE collection).
>> So I would expect to see MODULE* in most of the new function prototypes.
>> Along with loading and saving, one may have to know which MODULEs are in
>> a library, so in
>> comes MODULE *enumerating or listing*.
> That would be extra functions for enumeration/listing, for example
> List(library_name)=>list of[module names]
>> I'm not saying anything positive or negative about caching, or when or if
>> it should
>> happen.  I am open to suggestions on that.
> Not ready to say anything about that, probably is unneeded to change
> anything there at this moment. May be in the future with a library manager
> / HTTP_LIB /whatever, could start making sense.
>> I am not really even saying that this goal is achievable, since I have
>> not yet spent
>> sufficient time on it myself.  In the near term, if we can jam in this
>> PLUGIN interface,
>> and re-position PCBNEW on top of it with respect to MODULE access, then
>> we would then
>> pickup the following types of MODULEs, even without converting them
>> before using them:
>> *) legacy KiCad modules
>> *) s-expression module in nanometers
>> *) Eagle module libraries ?
>> *) GEDA libraries ?
> I think it's totally achievable.
>> Conceptually the work is like cutting an electrical cord, and outfitting
>> it with a defined
>> set of connectors, so that you can replace the downstream portion without
>> change to the
>> upstream portion.
> Yes, it's what I understood :)
>> Yes, we are talking about a software interface.
>> We have done this successfully for BOARDs. It works, in 45 minutes I
>> could put even the
>> specctra round-tripper into a PLUGIN.  Most if not all the import export
>> operations also.
>> The question is now, can we do it for MODULEs from libraries, and do it
>> in PLUGIN, or does
>> it take a lot more?
> I think it could, I'll finish my proposal and submit the patch to get
> opinions.
> --
> Miguel Angel Ajo Pelayo
> http://www.nbee.es
> +34 636 52 25 69
> skype: ajoajoajo


Miguel Angel Ajo Pelayo
+34 636 52 25 69
skype: ajoajoajo

Attachment: io_mgr_lib.patch
Description: Binary data

Follow ups