kicad-developers team mailing list archive

[Miguel Angel Ajo Pelayo <miguelangel@xxxxxxx>]

Hi Dick thanks for the reply :-)

2012/4/13 Dick Hollenbeck <dick@xxxxxxxxxxx>
>
> Hi Mike,
>
> Thanks for your time on this.


I'm happy to do it.

>[snip]

> >
> > 1)  Added to new plugin types:
>
> I don' think we don't need these 2 new enum values.  This support goes into LEGACY and
> KICAD plugins, respectively.  The idea is to bind the library technology with its
> corresponding board technology, in the collection of API functions.  This way a developer
> with knowledge on one kind of foreign file format set, can do a single plugin and get
> everything in there.
>

In that case, we will need to return a list of supported file
extensions for every plugin,
or do a

- static const wxString GetFileExtension( PCB_FILE_T aFileType );
+ static const wxArrayString GetFileExtensions( PCB_FILE_T aFileType );

or just:

+ static const wxString GetLibraryFileExtension( PCB_FILE_T aFileType );


 In the case of the legacy plugin we will have several file extensions
if we support
pcb (.brd) libraries (.dontremembernow) and components (.cmp)

> > [snip]
>
>
> The implementor of the plugin can indeed implement a subset of all the PLUGIN API
> functions.  Non-implemented ones return an error code.  The developer using the plugin
> will know this in advance for the time being, since he can see the source code, and not
> jump off a cliff not knowing his parachute package has no fabric in it.
>
> The PLUGIN api is a way or organizing functionality, is not a way of providing surprises.
>

Well, I was thinking about future dinamically loadable plugins
(.so/dll) or (.py) which anybody could install dinamically in the
software as a plugin. This is why I thought this way.


> >     c)  There is the case of opening/saving single componente files (.cmp?), that would
> > be almost the same plugin.
>
> I don't want to support that, unless it can be done with the plugin with special status,
> which is the "KICAD" plugin, and I think this is simply
>
> SaveModule() on the KICAD plugin.  It comes out in s-expression format, ALWAYS.  And
> because the "library" argument is actually only a directory for that plugin, you have your
> CMP file, but it is always s-expresion.

Yes, but for LEGACY plugin we might need it. Don't we?


> >
> > 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.
>
>
> Supporting a python plugin does not mandate dynamic C++ registration, if the python plugin
> is known ahead of time.  However, it is not clear to me that keeping an "in process"
> plugin in python is sensible.  The purpose of a plugin is to continually access a file of
> a particular format category, over and over, without actually committing to converting it
> over.

Well think of 3 different plugins installed together (and not compiled
in). They may need it's own id. But we will see this on the future,
doesn't make sense at this moment.

>
> If you want to write a file *converter*, and want to do it in python, it does not have to
> be a PLUGIN.  But if you want to seemlessly read and write EAGLE files, everyday of the
> week from KiCad, C++ is the better choice for that plugin.

Yes, but Imagine one day somebody writes for us a plugin that reads
and writes Ascii P-CAD, ascii protel, and he did because he could do
it without recompiling the whole kicad (which is not hard when you get
used to it, but it's a high barrier for most people)
>  [snip]

> > io_mgr_lib.patch
> >
> >
> > === modified file 'pcbnew/io_mgr.h'
> > --- pcbnew/io_mgr.h   2012-04-07 18:05:56 +0000

> > +
> > +    /**
> > +     * Function ListModules
> > +     * finds the requested PLUGIN and if found, calls the PLUGIN->ListModules(..)
> > +     * function on it using the arguments passed to this function.
> > +     * After the PLUGIN->ListModules() function returns, the PLUGIN
> > +     * is Released() as part of this call.
> > +     *
> > +     * @param aFileType is the PCB_FILE_T of file to load.
> > +     *
> > +     * @param aLibraryPath is the path to the library file or directory.
> > +     *
> > +     * @param aProperties is an associative array that can be used to tell the
> > +     *  plugin how to access the library file.
> > +     *  The caller continues to own this object (plugin may not delete it), and
> > +     *  plugins should expect it to be optionally NULL.
>
> I suppose we have to decide how and where we are going to support "searching".
>
> The aProperties argument may be one possibility, or we can do this higher up, in the C++
> MODULE realm.
>
> The latter keeps the plugin simpler.  Leaving it out of searching, but requires that every
> module be instantiated to do a rigorous search.
>
> Check client library code and let me know what you think.
>

What do you mean exactly for searching? , searching for parts in a
library with a wildcard?, I don't understand the relationship with
instantiating a module.  hmmm :-)



> > +    static MODULE* LoadModule( PCB_FILE_T aFileType,
> > +                                const wxString& aLibraryPath,
> > +                                wxString& aModuleName,
>
> I don't understand why you kept this argument, aAppendToBoard:
>

Well, just to be symmetrical to Load, and get your module "added" to a
board as you open it.

May be Load has it because you cannot do BOARD.Add(board) , right?

> > +                                BOARD* aAppendToBoard = NULL,
> > +                                PROPERTIES* aProperties = NULL);
> > +
> > +    /**
> > +     * Function SaveModule
> > +     * will write a module to an existing library, or just create the library
> > +     * if it doesn't exist
> > +     *
> > +     * @param aFileType is the PCB_FILE_T of file to save.
> > +     *
> > +     * @param aLibraryPath is the path of the library where we want the module
> > +     *  to be stored in.
> > +     *
> > +     * @param aModule is the module object that we want to store in the library.
> > +     *   The caller continues to own the MODULE.
> > +     *
> > +     * @param aProperties is an associative array that can be used to tell the
> > +     *  saver how to save the file, because it can take any number of
> > +     *  additional named tuning arguments that the plugin is known to support.
> > +     *  The caller continues to own this object (plugin may not delete it), and
> > +     *  plugins should expect it to be optionally NULL.
> > +     *
> > +     * @throw IO_ERROR if there is a problem saving or exporting.
> > +     */
> > +     static void SaveModule( PCB_FILE_T aFileType, const wxString& aLibraryPath,
> > +                              MODULE* aModule, PROPERTIES* aProperties = NULL);
> >  };
> >
> >
> > @@ -237,6 +325,81 @@
> >      virtual void Save( const wxString& aFileName, BOARD* aBoard,
> >                         PROPERTIES* aProperties = NULL );
>
>
> The last 3 functions should be virtual not static if they are to go into the PLUGIN interface:

Totally right :-)

I compiled doxygen but didn't try to make it compile the code yet, I
wanted to discuss first about implementation.


> Here we get the footprint name from the MODULE?  Seems probably good enough, but slight
> chance it will not be.
>
> > +     static void SaveModule( const wxString& aLibraryPath,
> > +                              MODULE* aModule, PROPERTIES* aProperties = NULL);

Yes, it's omited for that reason, but could be in the parameters too.
In which case could we need to change the module name?



--

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo