[Kicad-developers] potrace

kicad seems to have a copy of the potrace code in the tree. potrace_version.h claims this is version 1.12 the potrace website shows this changelog for 1.13 which was released on 22/10 Some critical bugs in the processing of BMP files were fixed. These bugs allowed the program to be crashed, or

Re: [Kicad-developers] help with 3D normals

Thanks Jose, I'll adjust the IDF plugin code to do just that - split the model so the top and bottom planes have 1 set of vertices and the vertical edge has smoothed vectors with Z=0. - Cirilo On Thu, Dec 17, 2015 at 1:44 AM, José Ignacio wrote: > Those artifacts look

Re: [Kicad-developers] [PATCH] Dark Theme Fixups

I'll shelve this patch for now since it's usefulness seems to be split depending on you OS. On 12/15/2015 7:36 PM, Simon Wells wrote: > I would prefer to see all the applications get a native toolbar for > their main toolbar, I have only hacked it on in the kicad manager > currently to see

Re: [Kicad-developers] PATCH : Enhanced Python Shell - Proposed version

Your patch fails to build using swig 3.0.6 on windows due to the comments you added to kicadplugins.i. Here is the output: C:/msys64/home/wstambaugh/src/kicad/product/pcbnew/../scripting\kicadplugins.i(101) : Error: Unknown SWIG preprocessor directive: The (if this is a block of target language

Re: [Kicad-developers] PATCH : Enhanced Python Shell - Proposed version

Hi Wayne, Thanks for testing this on windows, I really appreciate it a lot. I moved the offending comments from being inline comments and placed them into the Docstring. It has the added benefit of making them more visible to end users. See: http://i.imgur.com/Zq1pdyV.jpg (Apologies on the

Re: [Kicad-developers] help with 3D normals

Actually, I researched a bit better and it appears vrml has a concept of "crease angle" http://accad.osu.edu/~pgerstma/class/vnv/resources/info/AnnotatedVrmlRef/ch2-26.htm So you shouldnt split the mesh when saving to wrl, since a compliant viewer should take into account the creaseangle field

Re: [Kicad-developers] PATCH: To facilitate easier Via Curtain/Filling

Hi Steven,   my question are the side-effects of this patch, do you have checked all possible cases?   For instance if I'm retaining the nets, what happens if I've forgotten to erase tracks or vias in my design, would that create copper islands?   How can I discriminate between the

Re: [Kicad-developers] PATCH: To facilitate easier Via Curtain/Filling

Hi Torsten, Regarding the side effects, the patch actually eliminates a side effect, and introduces no others. As it stands, if a via/track is changed to unassigned, it has an impact on fill zones and then it IS possible for those zones to not fill properly and you can end up with

Re: [Kicad-developers] New development policies.

I think this is good, partly because I think calling it legacy canvas is more accurate (hence that is what I have called it always) and it is a stronger indicator that it is deprecated. On a side note to this, I think we might need to actually describe a bit better what the difference is on the

Re: [Kicad-developers] PATCH: To facilitate easier Via Curtain/Filling

Steve, You have written a well thought out argument for fixing the DRC. If we fix the DRC via checking code, your patch would be unnecessary. This is why I am reluctant to commit it. If I commit your patch, when we finally do get around to fixing the DRC, someone will have to remember to

Re: [Kicad-developers] help with 3D normals

Those artifacts look like duplicate vertexes with normals pointing different directions, ideally, for smooth shading wou'd want to break up the mesh on each facet of the model (ie: have all vertexes from the star pointing up, the other side pointing down and each side pointing perpendicular to

Re: [Kicad-developers] New development policies.

Due to the "Default Canvas" being called the "Legacy Canvas" is it not time to change it in kicad. The current naming of Default canvas also is a bit confusing as you would normally see the "Default" one listed as its name as well. The patch i have attached changes all references to Default

Re: [Kicad-developers] New development policies.

I was thinking it could just be a small description in on of the blog posts, alternatively an addition to one of the existing ones or just a completely new one. GAL versus default. 2015-12-16 16:40 GMT+01:00 Mark Roszko : > That's something that should be in the

Re: [Kicad-developers] New development policies.

That's something that should be in the documentation not website. We shouldn't be keeping documentation in two places. On Wed, Dec 16, 2015 at 10:16 AM, Nick Østergaard wrote: > I think this is good, partly because I think calling it legacy canvas > is more accurate (hence

[Kicad-developers] PATCH : Enhanced Python Shell - Proposed version

Hello List, I believe I have cleaned up my patch and made the enhanced shell do everything it should. It has a tabbed interface, with simple text editing capabilities. Its GUI can be used to introspect the full internal state of pcbnew, as exposed by the python interface. The editor can

Re: [Kicad-developers] GLM versioning

I'll bump this down to 0.9.5.1 until the new 3D viewer code is merged into the product branch. I may have to bump it back up during the merge but that may not be until after next ubuntu lts version is released so it may be less of an issue. On 12/16/2015 4:53 AM, Jean-Samuel Reynaud wrote: > So

Re: [Kicad-developers] GLM versioning

0.9.5.1 is definitely good enough for the main branch; it's only the new 3D work (which is still far from merging) which might require a higher version (or it might not - it hasn't been tested with 0.9.5.1). - Cirilo On Wed, Dec 16, 2015 at 7:58 PM, Jean-Samuel Reynaud

Re: [Kicad-developers] GLM versioning

Hi, Currently the version on CMakeLists.txt is 0.9.5.4. On Ubuntu 14.04 the available version is 0.9.5.1. Did I build a backport of libglm for ubuntu or 0.9.5.1 is enougth ? or other solution ? Regards, Le 05/12/2015 23:11, Cirilo Bernardo a écrit : > I had a look at GLM issues and it's a

Re: [Kicad-developers] help with 3D normals

Hi Cirilo, A "big picture" comment about the normals and normals in VRML: VRML does not support explicitly (or implicitly? O_o) "normals per-vertex-per-face". Take your file as reference, you stored vertex list, indexes list and "normals per-vertex" (== size of vertex list). So in this case