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 52 25 69 skype: ajoajoajo 2013/9/19 Miguel Angel <miguelan...@ajo.es> > 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
