kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

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 goals:


1) May not be necessary, may not be desirable for licensing reasons.  People have access
to the source, and can simply compile in their plugins, even if done as a patch not
included in the project yet.  At some point we have intended to support dynamically loaded
pcbnew PLUGINs, but these can still be known in advance, and are simply the existing
plugins jettisoned out into a DLL/DSO.  At that point, when there is a dynamic loader
specifically of pcbnew PLUGINs, there is greater incentive to put other conversion
functions under the PLUGIN api, such as specctra import/export, gencad, etc., since it
would make the initial load time of the main pcbnew program faster.


2) Your solution does not really address this issue.  I think scripts are good for things
which need to change fast, and must be personalized.  I think python is good for more than
scripts, high level file conversions, UI's etc.  For things which don't need tampering,
such as a pcbnew PLUGIN API implementation, C++ is a better choice for this super low
level API defined in pcbnew's PLUGIN interface.  But a person could put a python plugin
housing at a higher level


I think there is a place for python plugins, or UI scripts.  The housings
(loaders/receptacles) that enable those do not have to be pcbnew's PLUGIN interface.  You
would not plug your welder into your phone jack.  There can be different plugin interfaces
for various purposes.

IMO python housings (receptacles, loaders), should be higher up into the UI.

So I don't really share any enthusiasm for this proposal.

Soon we'll be switching over to the DLL/DSO versions of pcbnew and eeschema, exclusively.
 Actually this plan is *very much* more elaborated than I've had time to write up.  And it
is finally near the top of my to do list.

At that point, you can park your unit test framework on top, your wxPython work on top,
and identify where you want your python module housings to reside.  Somebody might even
want to rewrite kicad.exe in wxPython.

When I dump pcbnew.exe in favor of pcbnew.dll, there will be a small stub main() in a
smaller functionless pcbnew.exe, same for eeschema, so you can continue to run them as
normal from the command line.  But all the code is in the DLL/DSOs.

After that, python could command the blue sky above, if somebody wants to make that
happen.  You could substitute my stub loading main() pcbnew.exe with a wxPython version.

Dick