kicad-developers team mailing list archive

[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