On 10/04/2013 03:30 PM, Dick Hollenbeck wrote: > On 10/04/2013 03:15 PM, Wayne Stambaugh wrote: >> On 10/4/2013 3:22 PM, Dick Hollenbeck wrote: >>> >>>> >>>> Thank you for your amazing effort on the GitHub plugin. I am looking >>>> forward to taking it for a test drive. I hope to finish up the >>>> FP_LIB_TABLE code and documentation by the end of the weekend. With all >>>> of the pieces in place, KiCad should have a really good footprint >>>> library management system. >>>> >>>> Wayne >>> >>> >>> Thank you Wayne! >>> >>> I gave you bug https://bugs.launchpad.net/bugs/1235317 :) >> >> I noticed that :) I took a quick look at the module editor and saving a >> library may not be the only place where this will be a problem. The >> current code attempts to determine the correct plugin by the library >> path using IO_MGR::GuessPluginTypeFromLibPath().
Probably no environment substitution on lib path, if you want a quick hack. The GITHUB plugin is not useable until the stuff below is complete however, and it will get done in any case: The library browser needs to be based on the nickname now, for reasons I've mentioned in the last week. It appear that this is >> where things are causing the problem. I'll have to do a debug build on >> Linux with the GIT_HUB_PLUGIN enabled in order to test this so it might >> take me a day or so to get it all sorted out. > > The stuff below should be used in place of that, I have it on my to do list > already, as > you can see. > > If you don't want to do it, I will. > > >> >>> >>> I also updated FP_LIB_TABLE class with the following API extensions, in >>> *comment only* >>> form, just as a means of suggesting the API that we should be using in the >>> library manager >>> when FP_LIB_TABLE is enabled. These calls address all but the >>> >>> a) library creation, >>> b) library deletion >>> >>> functions, which I think may need to be done with the help of the >>> DIALOG_FP_LIB_TABLE. So >>> I defer those for now. >>> >>> If we park the PLUGIN::RELEASER into the FP_LIB_TABLE we can easily cache >>> the PLUGINs and >>> then these new API functions make sense. PLUGIN::RELEASER is not currently >>> up to the task >>> of operator=(), ( needed in ROW::operator=() ), but could be made so I >>> assume. >>> >>> Here are my suggested API function to bring into library management GUI, >>> and remove >>> references to ROW in there. The idea is that we get two primary benefits: >>> >>> Uppercase letters to show significant benefits: >>> >>> A) retention of every plugin's cache. >>> B) PROPERTIES can be passed to every PLUGIN::Footprint*() call. >>> >>> >>> Here are the new functions in class FP_LIB_TABLE, which one of us should >>> build into the >>> library browser and editor UI IMO: >>> >>> >>> #if 0 // PLUGIN API SUBSET, REBASED ON aNickname >>> >>> /** >>> * Function FootprintEnumerate >>> * returns a list of footprint names contained within the library given >>> by >>> * @a aNickname. >>> * >>> * @param aNickname is a locator for the "library", it is a "name" >>> * in FP_LIB_TABLE::ROW >>> * >>> * @return wxArrayString - is the array of available footprint names >>> inside >>> * a library >>> * >>> * @throw IO_ERROR if the library cannot be found, or footprint cannot >>> be loaded. >>> */ >>> wxArrayString FootprintEnumerate( const wxString& aNickname ) const; >>> >>> /** >>> * Function FootprintLoad >>> * loads a footprint having @a aFootprintName from the library given by >>> @a aNickname. >>> * >>> * @param aNickname is a locator for the "library", it is a "name" >>> * in FP_LIB_TABLE::ROW >>> * >>> * @param aFootprintName is the name of the footprint to load. >>> * >>> * @return MODULE* - if found caller owns it, else NULL if not found. >>> * >>> * @throw IO_ERROR if the library cannot be found or read. No >>> exception >>> * is thrown in the case where aFootprintName cannot be found. >>> */ >>> MODULE* FootprintLoad( const wxString& aNickname, const wxString& >>> aFootprintName ) const; >>> >>> /** >>> * Function FootprintSave >>> * will write @a aFootprint to an existing library given by @a >>> aNickname. >>> * If a footprint by the same name already exists, it is replaced. >>> * >>> * @param aNickname is a locator for the "library", it is a "name" >>> * in FP_LIB_TABLE::ROW >>> * >>> * @param aFootprint is what to store in the library. The caller >>> continues >>> * to own the footprint after this call. >>> * >>> * @throw IO_ERROR if there is a problem saving. >>> */ >>> void FootprintSave( const wxString& aNickname, const MODULE* aFootprint >>> ); >>> >>> /** >>> * Function FootprintDelete >>> * deletes the @a aFootprintName from the library given by @a aNickname. >>> * >>> * @param aNickname is a locator for the "library", it is a "name" >>> * in FP_LIB_TABLE::ROW >>> * >>> * @param aFootprintName is the name of a footprint to delete from the >>> specified library. >>> * >>> * @throw IO_ERROR if there is a problem finding the footprint or the >>> library, or >>> deleting it. >>> */ >>> void FootprintDelete( const wxString& aNickname, const wxString& >>> aFootprintName ); >>> >>> /** >>> * Function IsFootprintLibWritable >>> * returns true iff the library given by @a aNickname is writable. >>> (Often >>> * system libraries are read only because of where they are installed.) >>> * >>> * @throw IO_ERROR if no library at aLibraryPath exists. >>> */ >>> bool IsFootprintLibWritable( const wxString& aNickname ); >>> >>> #endif >>> >>> >>> These are now in the repo, but commented out. >>> >>> They mirror the similarly named ones in the PLUGIN class, but omit the >>> PROPERTIES* since >>> they are in the ROW, and aNickname takes the place of aLibraryPath. Good >>> symmetry otherwise. >>> >>> GITHUB plugin will yield great benefits from these changes, but will still >>> be too slow for >>> the "List All" footprint select dialog. I have a couple of ideas in mind >>> for that issue. >>> Having the "options" in place will give us more options, including COW >>> support, or >>> launching multiple threads to do the "List All" function. >>> >>> Again, I am deferring library create and delete into the future, and want >>> to think of >>> those processes as being fully subject to change when USE_FP_LIB_TABLE is >>> in play. >>> >>> >>> Dick >>> >>> >>> >> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~kicad-developers >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp >> > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
