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