kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 04/13/2012 09:00 AM, Miguel Angel Ajo Pelayo wrote:
> 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?

I already answered this question, no.  There is no point to saving a single footprint in a
obsolete format.


>
>>> 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 :-)

If the UI presents a method to search for keyword, do we want the plugin doing the
searching or the client code?

I say client code, for now.   This is different than in SWEET, where will immediately have
remote libraries.  We are not striving for that here and now in PCBNEW. 

Searching then requires that every module be loaded and searched in client code.  This
keeps the plugin simpler, and puts searching code in one place, higher up.


>
>
>>> +    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?

I already answered your question.  I like the original function prototype for now.