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 <stambau...@verizon.net>
> 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@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help : https://help.launchpad.net/ListHelp
> >
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
>
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
