kicad-developers team mailing list archive

[Miguel Angel Ajo Pelayo <miguelangel@xxxxxxx>]

As a proof of concept (with randomly swig-ed classes, etc...):

http://bazaar.launchpad.net/~miguelangel-r/kicad/scripting/revision/3444

With little work I managed to link to python and include a couple of
SWIG-ed modules
from our own code/classes.

The integration in pcbnew.cpp and CMakeList.txt it's a little dirty
yet, but it works.

I hope tomorrow could run something more useful than:

 154    PyRun_SimpleString("import sys\n"
 155                       "sys.path.append(\".\")\n"
 156                       "import kicad,pcbnew\n"
 157                       "from time import time,ctime\n"
 158                       "print 'Today is',ctime(time())\n");

Great! :)

2012/2/28 Miguel Angel Ajo Pelayo <miguelangel@xxxxxxx>
>
> Hi Dick,
>
> 2012/2/27 Dick Hollenbeck <dick@xxxxxxxxxxx>
>>
>> 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@xxxxxxxxxxxxxxxxxxx
>> 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




--

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