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 <[email protected]> > On 04/13/2012 09:00 AM, Miguel Angel Ajo Pelayo wrote: > > Hi Dick thanks for the reply :-) > > > > 2012/4/13 Dick Hollenbeck <[email protected]> > >> 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
io_mgr.patch
Description: Binary data
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
