← Back to team overview

kicad-developers team mailing list archive

Re: [PATCH] Re: SHAPE_LINE_CHAIN in swig?

 

This compiles cleanly and does not appear to have negative side effects so
I pushed it.  I made a small change to the boilerplate in math.i.

Keep in mind that the SWIG-based interface will (hopefully) be retired soon
in favor of a fully-abstracted KiCad scripting language.  But since that
goal is still in the future, this patch may be useful in the interim.

Thank you for your contribution to KiCad.
-S

Am Di., 24. Juli 2018 um 20:30 Uhr schrieb Andrew Lutsenko <
anlutsenko@xxxxxxxxx>:

> Hello,
>
> Can someone take a look at my patch please?
> It's my first so if I didn't submit it correctly please bear with me, I
> believe I did everything according to developers documentation.
>
> It would be great to see this in next release. Patch applies cleanly to
> both 5.0 branch and master.
>
> Regards,
> Andrew
>
> On Sun, Jul 22, 2018 at 6:05 PM Andrew Lutsenko <anlutsenko@xxxxxxxxx>
> wrote:
>
>> I figured it out, please see attached patch for the fix.
>>
>> On Sun, Jul 22, 2018 at 3:46 AM Andrew Lutsenko <anlutsenko@xxxxxxxxx>
>> wrote:
>>
>>> I tried adding this in kicad.i
>>>
>>> #include <geometry/shape_line_chain.h>
>>> %include <geometry/shape_line_chain.h>
>>>
>>> It compiles and SHAPE_LINE_CHAIN type shows up in pcbnew.py
>>>
>>> But I need VECTOR2I as well to get the actual coordinates. However
>>> adding math/vector2d.h header in a similar way leads to following
>>> linking
>>> error that I am not sure how to fix:
>>>
>>> D:/devtools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
>>> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.rdata$.refptr._ZN7VECTOR2IiE10ECOORD_MINE[.refptr._ZN7VECTOR2IiE10ECOORD_MINE]+0x0):
>>> undefined reference to `VECTOR2<int>::ECOORD_MIN'
>>> D:/devtools/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
>>> CMakeFiles/pcbnew_kiface.dir/objects.a(pcbnew_wrap.cxx.obj):pcbnew_wrap.cxx:(.rdata$.refptr._ZN7VECTOR2IiE10ECOORD_MAXE[.refptr._ZN7VECTOR2IiE10ECOORD_MAXE]+0x0):
>>> undefined reference to `VECTOR2<int>::ECOORD_MAX'
>>>
>>> Can someone who understands swig help me figure this out?
>>>
>>> On Sat, Jul 21, 2018 at 12:36 PM Andrew Lutsenko <anlutsenko@xxxxxxxxx>
>>> wrote:
>>>
>>>> Hello Kicad team,
>>>>
>>>> I'm writing a pcbnew action plugin that needs to read footprint pad
>>>> coordinates and shape.
>>>> I had no trouble figuring out all shapes except for custom one. It is
>>>> represented by SHAPE_POLY_SET which has a corresponding python type but
>>>> to
>>>> get actual vertex coordinates you have to either call one of Iterate()
>>>> variants or get polygon outlines with Outline(). They both return
>>>> objects
>>>> (ITERATOR and SHAPE_LINE_CHAIN) that are pointers and have no useful
>>>> attributes. As far as I understand they just don't have corresponding
>>>> swig
>>>> bindings so they are not exposed properly in python.
>>>>
>>>> Am I missing some obvious way to read custom pad polygon data in python?
>>>>
>>>> If not, what would it take to add that?
>>>>
>>>> I don't understand much about how swig configuration works but cursory
>>>> glance at Kicad source suggests that there needs to be an import for
>>>> shape_line_chain.h in common/swig/kicad.i, similar to shape_poly_set
>>>> import.
>>>>
>>>> If you are curious about what the plugin does, here are some of it's
>>>> results, generated from Kicad demos:
>>>> http://plugindemo.bitballoon.com/1/
>>>> http://plugindemo.bitballoon.com/2/
>>>> http://plugindemo.bitballoon.com/3/
>>>>
>>>> #2 above has a solder bridge with custom shape pads that are not
>>>> rendered.
>>>> Links are short lived.
>>>>
>>>> Regards,
>>>> Andrew
>>>>
>>> _______________________________________________
> 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
>

Follow ups

References