Miguel,
I can only see two references to goals (stated problems which need solutions)
in the
current design:
---1) load plugins that KiCad has never seen before, or does not know about in
advance.
---2) load python plugins.
Are you trying to address any other issues?
My responses to the 2
Clarification: making it generic means that we share the base class for
KICAD_PLUGINs and that we share the code for the manager.
Not that I intend to load pcbnew plugins into eeschema, or the other way
around.. which wouldn't have much sense.
Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636
On 09/19/2013 04:29 PM, 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
2013/9/19 Dick Hollenbeck d...@softplc.com
Miguel,
I can only see two references to goals (stated problems which need
solutions) in the
current design:
---1) load plugins that KiCad has never seen before, or does not know
about in advance.
Well, it must really know in advance about them
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
On 09/19/2013 04:31 PM, Miguel Angel wrote:
Clarification: making it generic means that we share the base class for
KICAD_PLUGINs and that we share the code for the manager.
Not that I intend to load pcbnew plugins into eeschema, or the other way
around.. which wouldn't have much sense.
How
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,
2013/9/19 Tomasz Wlostowski tomasz.wlostow...@cern.ch
On 09/19/2013 04:29 PM, 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,
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).
On 9/19/2013 10:37 AM, Tomasz Wlostowski wrote:
On 09/19/2013 04:31 PM, Miguel Angel wrote:
Clarification: making it generic means that we share the base class for
KICAD_PLUGINs and that we share the code for the manager.
Not that I intend to load pcbnew plugins into eeschema, or the other
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).
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,
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
On 09/19/2013 10:47 AM, Tomasz Wlostowski wrote:
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
So dick, if I'm not understanding the wrong thing, one of your concerns is,
that if we let other make plugins in scripting, that probably won't come
back as a contribution?
May be I'm plain wrong, but a piece of code that links (even dynamically)
to our binary, should be GPL/compatible license,
On 09/19/2013 02:14 PM, Miguel Angel wrote:
So dick, if I'm not understanding the wrong thing, one of your concerns is,
that if we let
other make plugins in scripting, that probably won't come back as a
contribution?
May be I'm plain wrong, but a piece of code that links (even
On 09/16/2013 02:21 AM, Miguel Angel wrote:
I have drafted a blueprint, on how we could implement a pluggable IO modules.
_https://blueprints.launchpad.net/kicad/+spec/pluggable-file-io_
If you have a moment, please give it a read, and comment on this thread or
edit over the
draft if you
Hi Dick,
No need to apologize, anyway I really appreciate the ping back...
I'm still thinking on the Tomasz suggestions, so, may be this night
I will do a 2nd round on the idea to include his design,
which seems more abstracted/general than my original draft.
About the options, sometimes
I have included Tom proposal as an extension to my original draft, it's a
little bit more intrusive, but may be it can be the seed for generalistic
plugins in KiCAD.
The draft, original version
http://pads.kicad-pcb.org/p/plugable-file-io/timeslider#1279 (if the #1279
is not working, just go to
On 09/16/2013 09:21 AM, Miguel Angel wrote:
I have drafted a blueprint, on how we could implement a pluggable IO
modules.
_https://blueprints.launchpad.net/kicad/+spec/pluggable-file-io_
If you have a moment, please give it a read, and comment on this thread
or edit over the draft if you feel
Hi Tomasz, thanks a lot for reading comments.
2013/9/16 Tomasz Wlostowski tomasz.wlostow...@cern.ch
On 09/16/2013 09:21 AM, Miguel Angel wrote:
_https://blueprints.launchpad.**net/kicad/+spec/pluggable-**file-io_https://blueprints.launchpad.net/kicad/+spec/pluggable-file-io_
Hi Miguel,
21 matches
Mail list logo
