Hi Andrew- Unfortunately your patch did not compile correctly in our qa system. It compiled for me (Linux/gcc 6) with only normal SWIG warnings but the qa system uses a different setup and encountered an error. You can view the output here: http://ci.kicad-pcb.org/job/kicad-qa/4415/
I suspect the issue will be resolved with some additional %ignore wrappers but haven't dug into it. In the meantime, I've reverted the commit until we can ensure it compiles with all systems. On the higher-order plans, you can view one of the relevant threads here: https://lists.launchpad.net/kicad-developers/msg36134.html I believe Thomas Pointhuber was thinking about developing that further in the near future. I'd recommend starting a new thread on the list to discuss this if you are interested in contributing. Best- Seth Am Mo., 30. Juli 2018 um 09:59 Uhr schrieb Andrew Lutsenko < [email protected]>: > Thank you Seth, > > Any chance this can be pushed to 5.0 branch too? > > > Keep in mind that the SWIG-based interface will (hopefully) be retired > soon in favor of a fully-abstracted KiCad scripting language. > > Oh. When that happens there hopefully will be a transition period to give > plugin writers a chance to migrate to this new language? > When you say fully-abstracted Kicad language, that means it's own syntax > and complete isolation from existing vast ecosystem of libraries that > python has? > Or is some interoperability planned? > > Regards, > Andrew > > On Mon, Jul 30, 2018 at 8:53 AM Seth Hillbrand <[email protected]> wrote: > >> 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 < >> [email protected]>: >> >>> 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 <[email protected]> >>> wrote: >>> >>>> I figured it out, please see attached patch for the fix. >>>> >>>> On Sun, Jul 22, 2018 at 3:46 AM Andrew Lutsenko <[email protected]> >>>> 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 <[email protected]> >>>>> 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 : [email protected] >>> Unsubscribe : https://launchpad.net/~kicad-developers >>> More help : https://help.launchpad.net/ListHelp >>> >>
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
