kicad-developers team mailing list archive

[Miguel Angel Ajo Pelayo <miguelangel@xxxxxxx>]

This is a first approach.

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

summary:

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

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

+    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&
aLibraryPath,
+                              MODULE* aModule, PROPERTIES* aProperties =
NULL);

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
library.

Notes:

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

Drawbacks:
    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
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo

Attachment: io_mgr_lib.patch
Description: Binary data