← Back to team overview

kicad-developers team mailing list archive

Re: Pluggable IO modules

 

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 <miguelangel@xxxxxx>

>
>
> 2013/9/19 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.
>>
>>
> 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
>>
>>
>>
>

Follow ups

References