kicad-developers team mailing list archive

[Miguel Angel Ajo Pelayo <miguelangel@xxxxxxx>]

Here it's the updated IO_MGR patch, some emails got lost in the middle,
I was unintentionally writing to Dick only, I wonder if there is some kind
of "always Reply all"
in gmail.

The main change is the Serialize / Unserialize for clipboard. :)


2012/4/13 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.
>
>
>
>
>


-- 

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

Attachment: io_mgr.patch
Description: Binary data