[Kicad-developers] msys2 ngspice-git package.

2016-09-18 Thread Wayne Stambaugh
I just submitted a pull request[1] for a new ngspice-git package for the msys2 project so you can build the latest version of ngspice from the head of the project git repo. This will allow you to build a version of ngspice that resolves the know simulation issues in the current stable release of

[Kicad-developers] [PATCH v2] [Git] Set some file attributes

2016-09-18 Thread Niki Guldbrand
* Added .gitattributes, with every file extension found in the repo. * Add context aware diff support to C/C++/HTML/Python, and: * Mark frag as C++. * Mark i as Python. * Mark patch files to be ignored during normalization, because some of the patches in patches/* have mixed line endings. *

Re: [Kicad-developers] Add a cmake option for legacy canvas

2016-09-18 Thread Wayne Stambaugh
On 9/17/2016 6:59 AM, Simon Wells wrote: > As legacy canvas in pcbnew is legacy is it worth conditional compiling > all the code related and only used by legacy canvas based on a cmake > option aka something like > > KICAD_BUILD_LEGACY_CANVAS with a default of ON, this will allow people > who

[Kicad-developers] [RFC] .gitattributes

2016-09-18 Thread Niki Guldbrand
Hi All. I would like a comment on my classification of the .gitattributes added by the attached patch. I have been trough every file extension found in the repo, and tried to clasify them. I would like to know if there are any special cases among them, other than *.bat, else I'll resend the

Re: [Kicad-developers] SWIG binding

2016-09-18 Thread Nick Østergaard
That sounds to me like it would make sense use kicad-python such that we can get yhe external API defined, and _ideally_ we could do whatever internally to kicad, let that be swig replacement or not. I suspect that having the external API defined would make it easier to find a better

Re: [Kicad-developers] [PATCH][RFC] Footprint wizards

2016-09-18 Thread Nick Østergaard
Hi Oliver The new checkbox works better i think. But thre is still some jumping around with it when it sort of "selected" by the cursor. Also it shows that small dashed box where there is usallly text for a checkbox it seems. This is on linux, I don't know if the same is seen on other platforms.

Re: [Kicad-developers] SWIG binding

2016-09-18 Thread Michael Steinberg
Hello all! Am 17.09.2016 um 23:39 schrieb Cirilo Bernardo: On Sat, Sep 17, 2016 at 2:08 AM, Tomasz Wlostowski > wrote: [...] I agree with all that as well. I think the best thing to do is create a PCB API which provides C

Re: [Kicad-developers] pcbnew tools uses long instead of intptr_t

2016-09-18 Thread Nick Østergaard
Ok, so maybe it was since the 2.6.5 update of freetype that those dependencies was added. KiCad uses boost, so of course boost is needed. The skip just skips downloading and building boost when building and uses the system boost. Also the option is obsolete now. 2016-09-18 15:02 GMT+02:00 Gustav

Re: [Kicad-developers] pcbnew tools uses long instead of intptr_t

2016-09-18 Thread Gustav Bergquist
libfreetype depends on libgraphite2 _pcbnew.kiface dependency chain: libfreetype > libharfbuzz > libglib > libpcre _pcbnew.kiface dependency chain: libfreetype > libgraphite2 libboost_regex dependency chain: libicuu > libicudt Why libboost is included i don't know. The -DKICAD_SKIP_BOOST=ON seems

Re: [Kicad-developers] [PATCH] Remove assert in pcbnew on osx with a debug build

2016-09-18 Thread Simon Wells
nickoe has commented on irc whether this is required on any platform, unfortunately i do not have any other platform for testing on, However the wxwidgets documention states that wxPaintDC should only be used in "native onpaint" handlers, what native means in this instance i am unsure, however on

Re: [Kicad-developers] pcbnew tools uses long instead of intptr_t

2016-09-18 Thread Nick Østergaard
2016-09-18 1:04 GMT+02:00 Gustav Bergquist : > Hello, > > I just managed to setup a build environment on windows and noticed that > kicad/pcbnew/tools/pcb_editor_control.cpp > kicad/pcbnew/tools/pcbnew_control.cpp > have when probably is more correct. > > See attached patches. > >