kicad-developers team mailing list archive

[Miguel Angel <miguelangel@xxxxxx>]

2013/9/19 Dick Hollenbeck <dick@xxxxxxxxxxx>

> 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.
>
>
Well, I agree that the implementation must be simple, yet I don't see the
reason that makes you disagree, the intention here is avoid code
duplication across the project, the drawback... I don't see it, but I
suppose there's something you're seeing...



> Look, Miguel.  Putting something on a website is not going to get it into
> the project.
>

Dick, the intention of sharing is discussing, make everyone more aware of
what other's ideas are, so they can think, propose, disagree, and come with
a better solution all together, so, when it's coding time, there is
agreement, and my coding effort maximizes benefit for the project, and it's
not a lost of time.

Sharing, planning ahead, and getting into the best solution. Always trying
to minimize discussion, even if there is some inherent need for that.


> 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.)
>
>
What's being done around this?, I thought it was done.

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?
>

 I wasn't aware, I understand your disagreement. here, a blueprint + a few
lines would have helped others not trying to step over your feet
unconsciously :(

It seems that I must read about your recent work.



(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.
>
>
Of course Dick, no intention on breaking your work. I will wait for it.


>
> 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.
>

But the fp_lib is only for libraries, and not pcb files, right?,  well.. I
need to wait and see Wayne's doc.

I expected that any plugin that the system loads, gets automatically in
place for use (avoiding users having to tune anything), I better wait to
see your code at work.


>
> High level languages should go on the top, lower level languages should go
> on the bottom.
>


I really don't agree about this, there is much benefit of having scripting
in the bottom/middle/parallel.


>  Just my broad perspective, and of that smart guy who came up with those
> names, high level
> language and low level language.


I think they were thinking about abstraction levels, more than stack
positions :)


>  I think there is far more important work to do in simply
> making the python environment work on all platforms.


I don't disagree on that, but what's missing about this? (after your work
and Brian's on Win32 I mean.) I have my own nightmares with OSX versions...

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.
>

What extra benefit do you expect from what we already have now in the
_pcbnew.so? (C++ direct interface, that one is clear, or running a pcb
"view" inside a wxpython interface or eeschema interface?)



> 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.
>

But, what do you miss exactly on the current python environment?,
for sure:
1) More examples
2) More documentation

Anything else?


>
> 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.
>
>
I don't know what you mean.



>
> Dick
>
>
>
>
>
>