kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 9/19/2013 12:51 PM, Miguel Angel wrote:
> 
> 
> Great Wayne, 
> 
>    Thanks a lot for your hard work.

Your welcome.  I just wish it didn't take so long to get it done.

> 
>   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 :)

The reason I want to wait until the documentation is complete is so that
we can QA the documentation as well as the code.  The documentation
needs to be clear so when the footprint library table becomes the
default build, using them is something average user can figure out from
the documentation.  Otherwise, the transition will be more painful than
it needs to be.

> 
> 
> 2013/9/19 Wayne Stambaugh <stambaughw@xxxxxxxxxxx
> <mailto: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
>     <mailto: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
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>     Unsubscribe : https://launchpad.net/~kicad-developers
>     More help   : https://help.launchpad.net/ListHelp
> 
>