kicad-developers team mailing list archive

[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