On Oct 5, 2013 10:30 AM, "Wayne Stambaugh" <[email protected]> wrote: > > On 10/04/2013 08:51 PM, Dick Hollenbeck wrote: > > On 10/04/2013 03:41 PM, Dick Hollenbeck wrote: > >> 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. > > > > > > Wayne, > > > > Attached is the full implementation of the new API functions. We just have to hook them > > into the UI now. > > > > The PLUGIN is instantiated in line 465 of the patched source. > > > > There was no need to support PLUGIN::RELEASER::operator=(), I made it private to get the > > compiler to whine. Plugins are instantiated lazily, at line 465. > > > > This is what we need to keep from destroying the PLUGINs between API calls and destroying > > our CACHE work. > > > > Dick > > > > > > This one fixes a comment which is important to the understanding of the wxASSERT() in each > > API function. FP_LIB_TABLE::FindRow() does not ever return NULL, so the comment is was > > wrong. If it returns at all, the result is not NULL. > > > > It also fully kills off FP_LIB_TABLE::PluginFind() > > > > I saw you just committed a bunch of changes to FP_LIB_TABLE. Did you > include this patch or did you want me to apply it? I figured out the > library save problem. What was happening is the library path was being > converted to a wxFileName which was stripping off the extra '/' which > converted: > > https://github.com/liftoff-sr/pretty_footprints > > to: > > https:/github.com/liftoff-sr/pretty_footprints > > which in turn caused wxUri to choke. I fixed it but if we are going to > implement the lazy caching scheme, does it make sense to continue to > deal with footprint libraries in this manner?
I committed the patch. With the new API functions, both guessing and libpath are de-emphasized. It is nickname centric, the api does most of the work for you. We just have to save nickname in the library manager in place of libpath. > > I should get this fix committed today and get back to finishing up the > rest of the footprint library table implementation. > > Thanks, > > Wayne > > _______________________________________________ > 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
