Hi Dick thanks for the reply :-) 2012/4/13 Dick Hollenbeck <d...@softplc.com> > > 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 _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
