On 09/19/2013 05:35 PM, 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?
Hi Dick,
A quick question: could you tell me how do you see loading STEP models
in the 3D viewer (in terms of interfaces and APIs involved)? I'm almost
sure we are on the same frequency, just using different modulations when
talking about plugins.
Regards,
Tom
_______________________________________________
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
