kicad-developers team mailing list archive

[Miguel Angel <miguelangel@xxxxxx>]

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

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