Hi Dick, 2012/2/27 Dick Hollenbeck <d...@softplc.com>
> On 02/27/2012 01:48 AM, Miguel Angel Ajo Pelayo wrote: > > I've been doing some experiments about that during the weekend, with > python as a first > > target, and using SWIG (which should be highly desired, as it's > something easier to > > mantain). > > > > And by now, what I found is that swig is quite mature, but mainly ready > for this: > > > > Python--->[extension]/extension_wrap.o ---->library.so > > > > This is one of our intended usages, but, for usage inside kicad: > > > > Kicad<--->Python-->extension--->Kicad > > > I think to accomplish all our goals, we will have to split PCBNEW and > EESCHEMA into at > least two parts each, perhaps three. (Third part might be the graphics > functions.) This > means you keep a main() part, and have one or two DLL/DSO's beneath that > main process > entry point. This is my vision even *before* SWIG enters into it. > It's finally not important for swig to have a DSO, but if it was in the plan anyway the final code must be much more clean. > This lets you then have a replaceable main() part, that is a number of > alternative > implementations of the top level process entry point. EESCHEMA and > PCNBEW core document > functions are held in what is essentially shared libraries. > > > I foresee at least 3 such alternative top main() parts: > > a) simple command line processing main() without a scripting language. > Aha, like for simple task that could be scripted, like printing, plotting into gerbers, rendering thins, I suppose, right? > > b) scripting language main(), for any SWIG favorite language(s). > For this, and having all the functionalities as DLLs/DSOs, we could go the swig-standard way, using any interpreter as... python-->[eeschema-module]--->eeschema-lib lua-->[eeschema-module]-->eeschema-lib whatever-favorite-script-->[,,,]--->[...] > > c) normal UI main() where the wxFrame and Dialogs reside. > > For the final use case, which is normal UI but also with scripting: > > Once you have this split (or these split_s_, if you consider a second > DLL/DSO for drawing > functions), then like mortar in between two stacked bricks, there is a > place to put a shim > in there, that is inject something below c) to handle the case where you > want the normal > UI but also want scripting. > Yes, that should be interesting, so people could load plugins into kicad in the form of scripts (like exporting/importing/special automated functions...) and assign them to hotkeys or system callbacks. > > > It may require some hacking. > > Your word, not mine. I don't ever remember having hacked any code. :) > Well, the "hacking" won't be needed, it's not the standard case but it seems that the swig people already thought of this. So we could do it *without *breaking anything around (modifying swig, or patching swig's out...) And as python has already wx libraries, for the UI part it musn't be that bad :-) (as long as now wx is loaded dynamically...) it could work... > > > They had an embed.i that can be a start point. The problem is that SWIG > build wrapper > > modules that are ready to be loaded from python, but they include all > the swig logic. So > > then, if we linked kicad + python lib + wrapper_kicad.cxx + > wrapper_eeschema.cxx + > > wrapper_pcbnew.cxx then the swig code would be x3 times. > > > I mention all this so that you understand what we have been talking about, > and don't > forget the BOARD_ACTION class, which is also still missing. This is a > way of pulling > non-UI verb type code down into the DLL/DSO layer without distancing it so > far that it > cannot still be part of the c) wxFrames above. I talked about using > multiple inheritance > to bring BOARD_ACTION back into the frame. Doing this across a DLL/DSO > chasm will be a > trick, but it might be possible. If it cannot be made to work, we can > fall back to > separate link images, where you simply have identical code in a number > places. > > Yes of course, now I opened a kicad-scripting branch, to do some first (dirty) tests and confirm the feasibility of the project using SWIG, so we could later go and use the same build scripts / techniques for BOARD_ACTION (or any other parts) with very little effort and very little maintenance. Greetings :-) > > 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 > -- Miguel Angel Ajo Pelayo http://www.nbee.es +34 636 52 25 69 skype: ajoajoajo
_______________________________________________ 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