kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On Oct 5, 2013 10:30 AM, "Wayne Stambaugh" <stambaughw@xxxxxxxxxxx> 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     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp