← Back to team overview

kicad-developers team mailing list archive

Re: Kicad + V8/NodeJS/Swig [split from kicad ideas mail]

 

Dick, Thanks a lot for the feedback.

1) I suspected that the wxString was used to take care of filename
encondigs. It makes sense. Thanks for your confirmation.
I'll try to look at the wxPython project to see how do they handle the
wxString objects :)

2) Sorry for my poor explanations, I will try to explain the problem I
found more clearly:

Right now, when we swig-out our code we get 2 wrappers (it could be just
one), one is kicad with general classes and definitions
and the other is pcbnew. Those wrappers, play well together. And it's swig
implementation takes care of converting objects from
C++ to script, and back, everything seems fine there.

The problem comes here:  If I import wxPython from my python script. At
this moment, the wxPython wrappers are loaded, and it
seems that a "wxPoint*" object wrapped from our software is different that
a "wxPoint*" wrapped from the wxPython. Both
swig wrappers (ours, and wx) don't seem to play well together. They can
run, but we cannot get a wxPoint or wxString from one
wrapper and pass it (directly) to the other.

For now, it's perfect to build just some wrappers for wxString, wxPoint,
wxRect, our basic dependencies, and we will be able
to use our api without any problem.

3) About the missing roadmap points, please ask me to add anything I
forgotten, I'm very sorry about that. Of course, this is
only for pcbnew,  this must be replicated for eeschema, etc. But it's
better to do it one step at a time :)


4) About the QA tests, yes, they are not very hard to do, and it's a good
way to test the full set of wrappers. About swig imports coming out of sync,
it shouldn't be a problem, they generate the class imports from our .h
headers. They could become out of sync if we don't use the .h headers
(to hide unwanted parts) or if we add some extra python(script) written
helpers.




2012/3/5 Dick Hollenbeck <dick@xxxxxxxxxxx>

>
> > I will keep working on it, and keep you updated, my "roadmap" may look
> like this:
> >
> > 1) End the wrapper for BOARD objects, and all the objects inside a board.
> > 1.b) Add wrappers to basic objects like wxString, wxPoint, etc...
> > 1.c) Clean up the GetBoard() implementation I did now (just for test)
> > 2) Wrap the KICAD_PLUGIN + BOARD objects, to make "kicad/pcbnew" modules
> importable from
> > scripts.
> > 3) Make some QA tests to check the our new scripting classes
>
>
> I like number 3).  If the SWIG definitions are not regularly built and
> tested, we can well
> imagine how they could become out of sync.  Thanks for thinking of this.
>
>
> >
> > Stepping up for this job it seems more and more feasible to me, as I
> solve the little
> > problems that I'm finding around it
> > should be something easy to do and maintain
> >
> > Greetings,
> > Miguel Angel Ajo
> >
>
>


-- 

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

References