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