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 |-- * Make the C++<-->Python facade for those classes (one by one in separate implementations, and see how they work, so we can refine the implementation before we implement the next) * Make a contextmenu example (component alignment: horizontal/vertical) Miguel Angel Ajo Pelayo http://www.nbee.es +34 636 52 25 69 skype: ajoajoajo 2013/9/19 Miguel Angel <miguelan...@ajo.es> > > > 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 (having any subclass for > the 'PLUGIN' proposed class, that really implements an interface for the > plugin itself) > > They idea is just sharing the same load/unload/reload/enumerate > functionality for all plugins types. > > >> ---2) load python plugins. >> >> > Well, this is my *main* goal in the end. > > Loading python plugins that can export/import as the native C++ ones. > > >> >> 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. >> >> > Well, if this is the advantage, I don't think some extra KB's will do any > bad to todays machines, so, may be the licensing concerns may have more > weight than the runtime? What do you think about this? > > > >> 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 python implementation of IO/plugins, can be done without *any* > change to the current PLUGIN implementation (see my first proposal), but > the dynamic insertion on IO_MGR for new plugin modules. > > In the end, it's just a script that takes a board or library, and renders > an output, or the other way. > > I haven't put the exact details on how to do this, but on how to change > current implementation to allow the load of "PLUGIN"s dynamically. > > I think letting people do this, would bring more importers & exporters to > kicad, because we break the C++ entry barrier that it does exist for many > people with an interest on this. > > >> 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. > > > Yes, that's the second proposal, providing a more wider sense of > general-plugin, with derivative classes that can have different interfaces > (depending on the general-plugin subclass) > > >> You >> would not plug your welder into your phone jack. There can be different >> plugin interfaces >> for various purposes. >> >> That's the idea. > > >> IMO python housings (receptacles, loaders), should be higher up into the >> UI. >> > > What do you mean? Action plugins/Context menu plugins/Hotkey plugins/Event > plugins, etc? > > That's next on my list, but may be they're more useful than the IO plugins. > > I have no problem in switching priorities, but yet, it's not bad if we set > the foundations for a "generic-plugin" manager that can be subclassed by > all kind of plugins that we find interesting. > > >> So I don't really share any enthusiasm for this proposal. >> > > Well, rethinking about it, the UI seems something better (more useful) to > start making "pluggable"... > > >> 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, >> > > I think I will start a demo of the unit test framework as soon as it's > possible (after I manage to finish the python auto doc..). > > >> and identify where you want your python module housings to reside. >> Somebody might even want to rewrite kicad.exe in wxPython. >> > > It may become possible, I suppose. > > >> >> 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
