kicad-developers team mailing list archive

[Miguel Angel <miguelangel@xxxxxx>]

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?



Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo


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