kicad-developers team mailing list archive

[Miguel Angel <miguelangel@xxxxxx>]

Great Wayne,

   Thanks a lot for your hard work.

  Let us know as soon as it's ready. I will keep my mind thinking on how to
QA kicad better,  and I can get back into this when I see your work :)


2013/9/19 Wayne Stambaugh <stambaughw@xxxxxxxxxxx>

> On 9/19/2013 11:35 AM, Dick Hollenbeck wrote:
> > On 09/19/2013 09:29 AM, Miguel Angel wrote:
> >> Ok, summarizing all the feedback:
> >>
> >> I'd defer this blueprint proposal, and switch it into something like:
> >>
> >> * Making a generic system wide plugin load system,
> >>  (load/unload/reload/enumerate/instantiate). Supporting statically
> loaded C++ plugins, and
> >> dynamically loaded python plugins.
> >>
> >> KICAD_PLUGIN
> >> /|\
> >> [PCBNEW_PLUGIN]
> >> /|\
> >>  |-- CONTEXTMENU_PLUGIN
> >>  |-- HOTKEY_PLUGIN
> >>  |--TOOLBAR_PLUGIN
> >>  |--
> >
> >
> > Sorry, I do not agree.  The dynamic loading is mostly already done for
> you in a couple of
> > wx functions.  So this is trivial, and not worth even discussing.
>  Trying to establish a
> > common class hierarchy for it is not worth the effort, just to share two
> functions which
> > are already outside the class anyway, in the wx library.  There after,
> because the API
> > that you are eventually calling into after the plugin is loaded is
> different, there is no
> > need for any commonality.
> >
> > Look, Miguel.  Putting something on a website is not going to get it
> into the project.
> > You have to establish agreement among the lead developers.  This is me,
> Wayne, and JP.  On
> > the subject of pcbnew PLUGINs, Wayne and I have championed the effort,
> and until two days
> > ago, our vision has yet to be realized.  (Working 4.5 hours per week on
> KiCad over a year,
> > you cannot exactly get a lot done fast.)
> >
> > Can I be candid in saying that to have our work coming under question
> just two days after
> > Wayne did the near to last commit, is a little hard to take?
> >
> > (Until the fp lib table manager was complete, you don't see the full
> benefits of the
> > PLUGIN api.)  Wayne did his part, and that was the big part.  I have
> some dialog
> > enhancements to make, but it is my understanding that it might be worth
> testing now.
>
> I'm going to do my best to get the documentation completed this weekend
> and send out an announcement for general testing.  The code is pretty
> much ready to go but I would like the documentation in place so I
> (hopefully) don't have to answer too many questions.
>
> Wayne
>
> >
> >
> > If you want to load a python module under the PLUGIN API, then write a
> C++ adapter, once,
> > as PLUGIN derivative, that can load any python class implementing the
> interface or a
> > subset of it.  Then, in the fp_lib_table, you can name your python
> module in the options
> > column.  The PLUGIN ADAPTER can take an option string and load the
> correct python module,
> > and fullfill the  Footprint*() subset of the PLUGIN API.  This is
> however, probably
> > getting the cart before the horse.
> >
> >
> > High level languages should go on the top, lower level languages should
> go on the bottom.
> >  Just my broad perspective, and of that smart guy who came up with those
> names, high level
> > language and low level language.  I think there is far more important
> work to do in simply
> > making the python environment work on all platforms.  Tasks like
> directory selection,
> > module locations, terminology establishment, path establishments, and
> higher level plugin
> > interface definitions.
> >
> > Your very important work on creating the DLL/DSO that house the
> pcbnew.{so,dll} files is
> > what I want to extend (for builds with and without python) so that you
> can park a whole
> > new world of python on TOP.
> >
> > Again, we are not idea limited, but time limited.
> >
> > What we need you doing is to run with the blue sky above the existing
> C++ work.  Imagine
> > the different mindset that could exist if it was a python program that
> dynamically loaded
> > the pcbnew.so to run it in interactive UI mode?  Now all your threads
> are wxPython
> > threads.  And, you have to firmly establish a *working* python
> environment way up front.
> >
> > Folks do not want to load the exe and have it whine about not finding a
> python module,
> > because some path or package has yet to be installed.  That is the first
> task I think,
> > other than getting the DLL/DSOs in place for exclusive use.
> >
> >
> > Dick
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > 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
> >
>
>
> _______________________________________________
> 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
>