[Kicad-developers] warning: enum constant in boolean context in dialog_print_generic.cpp

Hi Orson and KiCad devs, During rebuilding current nightly I noticed this warning and decided to look into it. /usr/local/google/home/alutsenko/src/kicad/common/dialogs/dialog_print_generic.cpp: In member function ‘virtual void DIALOG_PRINT_GENERIC::onCloseButton(wxCommandEvent&)’:

Re: [Kicad-developers] Some of our symbols currently still have invisible power pins. We want to fix this but want to give you guys a chance for input first.

Hi Rene- Am 2018-11-06 16:41, schrieb Rene Pöschl: Sadly we did not come around to fix all symbols before the v5 release. We now seem to have a volunteer who would be prepared to fix these symbols. There is a catch though. Whatever we do to fix this it will break designs that use the old

Re: [Kicad-developers] Some of our symbols currently still have invisible power pins. We want to fix this but want to give you guys a chance for input first.

Only logic family libs are affected. The 4xxx lib is already done. This leaves 4 libs at most. (I have no access to kicad right at this moment so i can not check.) Only option 2 ends up with multiples of the lib. In option 3 we will rename the lib (meaning a new lib will be added and the

Re: [Kicad-developers] Some of our symbols currently still have invisible power pins. We want to fix this but want to give you guys a chance for input first.

Hi, Rene. Thanks for bringing this up. I've never liked hidden power pins. In my opinion, the python philosophy applies here too: "Explicit is better than implicit." How many libraries will need this? I'm asking because, if we went for option 3 (or 2), will we end up with a lot of nearly

Re: [Kicad-developers] [PATCH] Option to not render 3D models for footprints

Hi Oliver, I was about to bump your email too :) > 2) The m_Preview parameter is saved to file (both .kicad_mod and .kicad_pcb) At the time I worked on the 3D Viewer, some ideas arise that involve to add new tags to the .kicad_pcb I understood that at that time it was not a good time to

[Kicad-developers] Some of our symbols currently still have invisible power pins. We want to fix this but want to give you guys a chance for input first.

Hi all, Sadly we did not come around to fix all symbols before the v5 release. We now seem to have a volunteer who would be prepared to fix these symbols. There is a catch though. Whatever we do to fix this it will break designs that use the old symbols right now. So we have a few

Re: [Kicad-developers] [PATCH] Option to not render 3D models for footprints

Bump :) On Tue, Oct 30, 2018 at 11:27 PM Oliver Walters < oliver.henry.walt...@gmail.com> wrote: > The attached patchset expands on the "Preview" checkbox in the 3D model > tab in the footprint editor. > > This "Preview" option currently only applies to the preview window. > However if the user

Re: [Kicad-developers] Python shebangs

I don't think this is an issue outside of Fedora. On Tue, Nov 6, 2018 at 8:45 AM Steven A. Falco wrote: > I'd like to have a discussion about python shebangs. I noticed several > rpmlint errors when building the official Fedora packages. Specifically, > rpmlint is complaining about using

Re: [Kicad-developers] Python shebangs

On 11/6/2018 11:15 AM, Simon Richter wrote: > Hi Steven, > > On 06.11.2018 15:45, Steven A. Falco wrote: > >> I've done a little research, and apparently, the concern is that "env" may >> find a locally installed python interpreter that doesn't work the same as >> the system python

Re: [Kicad-developers] Python shebangs

Hi Steven, On 06.11.2018 15:45, Steven A. Falco wrote: > I've done a little research, and apparently, the concern is that "env" may > find a locally installed python interpreter that doesn't work the same as the > system python interpreter, and that can result in subtle bugs. Of course the >

Re: [Kicad-developers] Arch build failures with glm 0.9.9.3-1

Hi, I've tracked it down to the following conditions: * glm includes commit 68c7e7e50 (e.g. 0.9.9.3) * C++11 (before is OK, C++14 is OK) * The define GLM_FORCE_PURE is set (KiCad does this in xv3d_types.h) I've filed a bug upstream at glm [1]. Notable line in the GLM manual: "The use of

Re: [Kicad-developers] Arch build failures with glm 0.9.9.3-1

It also breaks msys2/mingw32/mingw64 builds. :( On 11/6/2018 9:19 AM, John Beard wrote: > Hi, > > Just a quick word of caution: I can can't get KiCad to build with glm > version 0.9.9.3, which was updated yesterday. > > The responsible change in glm appears to be 68c7e7e50 [1], which deals >

[Kicad-developers] Python shebangs

I'd like to have a discussion about python shebangs. I noticed several rpmlint errors when building the official Fedora packages. Specifically, rpmlint is complaining about using "env" as a method for locating the python interpreter. Here are the errors: kicad-doc.noarch: E:

[Kicad-developers] Arch build failures with glm 0.9.9.3-1

Hi, Just a quick word of caution: I can can't get KiCad to build with glm version 0.9.9.3, which was updated yesterday. The responsible change in glm appears to be 68c7e7e50 [1], which deals with constexprs in GCC. There are various errors in the 3d-viewer [2]. However, I am not sure if this is

Re: [Kicad-developers] Build error on Fedora KiCad copr

Thank you, I can confirm that this was the last change that made the fedora build happy. :) On Mon, 5 Nov 2018 at 20:33, Wayne Stambaugh wrote: > > John, > > I merged your patch. > > Thanks, > > Wayne > > On 11/5/2018 9:49 AM, John Beard wrote: > > Gah! Wrong patch! Try this. > > On Mon, Nov 5,