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 <d...@softplc.com> > 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 > >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
