kicad-developers team mailing list archive

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