2013/9/19 Dick Hollenbeck <d...@softplc.com>
> 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
>
>
>
>
>
>
_______________________________________________
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
