← Back to team overview

kicad-developers team mailing list archive

Re: Pluggable IO modules

 

On 09/19/2013 02:14 PM, Miguel Angel wrote:
> 
> So dick, if I'm not understanding the wrong thing, one of your concerns is, that if we let
> other make "plugins" in scripting, that probably won't come back as a contribution?
> 
> May be I'm plain wrong, but a piece of code that links (even dynamically) to our binary,
> should be GPL/compatible license, isn't it? 


That is two questions.  Both are good ones.  There are more questions to ask and answer.
And it gets complicated if you make it a multi-language concern.

Since KiCad is GPL not LGPL, I would say any code sitting on top of KiCad must be GPL.  We
do not have the same thing as linux's system call boundary.  You are using KiCad even if
you dynamically link to it, which a wxPython app would be, which a 3rd party C++ app would
be.  Python or C++ or whatever.  We have this concern as we become a DLL/DSO by default,
as the normal binary form of KiCad.

For *scripts* which sit under KiCad, I am uncertain, and open to other's opinions.  We
have goals and we have rights.  Our rights might be more limited than our goals, thus
making goal unachievable.

For C++ plugins, it is our *desire* to get these rolled into KiCad, but I don't see how we
can enforce this (except by not having C++ plugins, and asking for built in C++
implementations).  But I am not thinking this is so important that it establishes a
technical decision.  A technical decision can be a left to a purely technical answer if we
decide that.


=============

On the python support, I am sure Brian and I have as much into it as you do, and our goals
are probably similar.

You asked me for a list for you concerning what needs to still be done to make the python
build "work".  I want to make the python "install" work, not just the build work, so the
user experience is such that he sees a cohesive solution.

But I do not have time right now to do a write up.  Our goals are the same, just remember
that.  If folks stumble with the python support, take that as feedback, fix it.

I still think it is too early to get all worked up about it.  Things will begin to clarify
after you see what I am doing with the "main-module" DLL/DSOs.

As I said, things begin to look different when you realize the top most thread is or could
be already running a python interpreter, instantiated well above these little UI scriplets
that you want to weave into the UI.  Interpreter instantiation with python is not trivial,
and the notion of sub-interpreters comes into play if you already have one elsewhere in
the process.

wxPython's availability changes much, in terms of where you can do what, and where you can
first instantiate the interpreter.

It is too early to get all worked up about it.  The full foundation is not in place yet.
It is not.  We are getting there however, as I said.


I know you are using other tools than boost::python, and that is fine.   There are a
couple of things that boost::python solves.  I wonder if it solves the interpreter
instantiation problem, at the top level, in a good way.  Note that I am NOT advocating for
or against it elsewhere, just at the top.  They have a nice C++ inline called

eval( "python expression" );

and about 2 other gems that are worth looking at as header only (i.e. inline) functions.


Dick



> 
> 
> 
> Miguel Angel Ajo Pelayo
> http://www.nbee.es
> +34 636 52 25 69
> skype: ajoajoajo
> 
> 
> 2013/9/19 Dick Hollenbeck <dick@xxxxxxxxxxx <mailto:dick@xxxxxxxxxxx>>
> 
>     On 09/19/2013 10:47 AM, Tomasz Wlostowski wrote:
>     > On 09/19/2013 05:35 PM, Dick Hollenbeck wrote:
>     >> On 09/19/2013 09:29 AM, Miguel Angel wrote:
>     >>> 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
>     >>>   |--
>     >>
>     >>
>     >> Sorry, I do not agree.  The dynamic loading is mostly already done for you in a
>     couple of
>     >> wx functions.  So this is trivial, and not worth even discussing.  Trying to
>     establish a
>     >> common class hierarchy for it is not worth the effort, just to share two functions
>     which
>     >> are already outside the class anyway, in the wx library.  There after, because the API
>     >> that you are eventually calling into after the plugin is loaded is different, there
>     is no
>     >> need for any commonality.
>     >>
>     >> Look, Miguel.  Putting something on a website is not going to get it into the project.
>     >> You have to establish agreement among the lead developers.  This is me, Wayne, and
>     JP.  On
>     >> the subject of pcbnew PLUGINs, Wayne and I have championed the effort, and until
>     two days
>     >> ago, our vision has yet to be realized.  (Working 4.5 hours per week on KiCad over
>     a year,
>     >> you cannot exactly get a lot done fast.)
>     >>
>     >> Can I be candid in saying that to have our work coming under question just two days
>     after
>     >> Wayne did the near to last commit, is a little hard to take?
>     > Hi Dick,
>     >
>     > A quick question: could you tell me how do you see loading STEP models
>     > in the 3D viewer (in terms of interfaces and APIs involved)? I'm almost
>     > sure we are on the same frequency, just using different modulations when
>     > talking about plugins.
>     >
>     > Regards,
>     > Tom
> 
> 
>     Tom,
> 
>     Before I would talk about plugins I would always be sure I have enough interface
>     implementations to justify a plugin manager.  To me, a plugin is a dynamically loaded
>     module.  It implements an interface, at least one.  An interface implementer does not need
>     to be a plugin.  So you would need a count of implementations before it is worth
>     continuing on the topic of plugins.  Then multiply that count times the average size to
>     figure out the number of bytes you are jettisoning out of the RAM area for the case where
>     you need not use the interface at all.
> 
> 
>     In an open source project, the source is available to any one who wants to make a plugin.
>      It is not too much to ask users or a sponsor to compile to get a new implementation of an
>     interface.  The plugin is not the only way.
> 
>     class wxDynamicLibrary
> 
>     Can either both
> 
>     1) manage DLLs or
>     b) not manage them, but load/unload them
> 
>     in a cross platform way.
> 
>     Here are your unmanaged, i.e. mode b) functions:
> 
>         static wxDllType RawLoad(const wxString& libname, int flags = wxDL_DEFAULT);
> 
>         // unload the given library handle (presumably returned by Detach() before)
>         static void Unload(wxDllType handle);
> 
>     =================================================================
> 
>     The art of software design hinges on interface design, not plugin design.  This is the
>     careful crafting of functions, and also of locating that interface within the software
>     stack.
> 
>     Again, plugin discussion may never even need to happen, if your number of interface
>     implementations does not justify it.
> 
>     If this is not your definition of plugin, well then, I suppose then we'd have to both go
>     agree on what dictionary we'll use to even have a conversation.
> 
>     I chose the term PLUGIN for the pcbnew interface that I designed because I suspected that
>     eventually we would be bringing in a large number of conversion functions under that API.
>      (The last word in API is *interface*.)
> 
>     PLUGIN::Load() for example, if you look at it carefully, could be used for the specctra
>     back import.  PLUGIN::Save() could be used for specctra DSN output.  So those two
>     functions constitute a generally useable API (interface), that therefore invites
>     widespread use.
> 
>     But we continue to write code that does not use this API.  Netlist exporters, gerber
>     exporters, etc.  If you want to use the main benefit of a plugin, memory savings, then you
>     write DLL/DSOs to implement your *interface*.  If not, then you can use that interface as
>     part of a monolithic link image.  For commercial software, you get additional benefits,
>     but I won't recognize those in an open source package.  People can build and add a new
>     plugin by compiling it in.  Memory savings are the main benefit in an open source package
>     to a plugin system.
> 
> 
>     In the end, interface design is where you make or break the software package, not plugin
>     design.
> 
>     What I do know is that interfaces are all different typically, so therefore I am even more
>     reluctant to have a combined conversation about plugins, when I am reluctant to have even
>     one conversation about a single plugin until its need is established.
> 
> 
>     Dick
> 
> 



References