Re: [Kicad-developers] New package for macOS 5.1.2 stable including ngspice-30 ?

2019-06-21 Thread Nick Østergaard
I see no reason to make ngspice 30 a strict minimum requirement. Lets just help packagers update to the latest ngspice and we are good. tor. 13. jun. 2019 18.33 skrev Wayne Stambaugh : > On 6/10/19 4:01 PM, Carsten Schoenert wrote: > > Hello Wayne, > > > > Am 10.06.19 um 20:15 schrieb Wayne Stam

Re: [Kicad-developers] 6.0 Zone filling differences

2019-06-21 Thread Frank Severinsen
hi Jeff This actually also solves this: Den 21. juni 2019 kl. 00.49.55 +02.00, skrev Jeff Young : > On the master branch in my repo > () I have pushed the new zone > algorithm, new solder mask shape

Re: [Kicad-developers] 6.0 Zone filling differences

2019-06-21 Thread Jeff Young
Hi Frank, While it improves the WYSIWYG situation, it doesn’t quite fix it. In particular it still doesn’t handle mask drop-out between pads due to the the mask minimum width being subceeded. Cheers, Jeff. > On 21 Jun 2019, at 12:08, Frank Severinsen > wrote: > > hi Jeff > > This actuall

Re: [Kicad-developers] 6.0 Zone filling differences

2019-06-21 Thread Wayne Stambaugh
Jeff, Users are going to expect chamfering if there is an option for it. I don't see how you are going to avoid adding chamfering to the spokes unless we decide to do away with chamfering as an option. I don't think that's good idea because right angles on board geometry is generally frowned upo

Re: [Kicad-developers] 6.0 Zone filling differences

2019-06-21 Thread Seth Hillbrand
Hi Wayne- I don't think that the relief chamfering is controlled by that option. We also don't chamfer the connection on the way into the pad, so I'd tend to agree with Jeff that the extra corner chamfer on only one side of the connection might be unnecessary. It looks like the original kno

Re: [Kicad-developers] 6.0 Zone filling differences

2019-06-21 Thread jp charras
Le 21/06/2019 à 00:49, Jeff Young a écrit : > On the master branch in my repo > (https://git.launchpad.net/~jeyjey/kicad/tree/) I have pushed the new > zone algorithm, new solder mask shape generation, and new pad painting > (which now is the same as the plot code). > > These changes address: > >

Re: [Kicad-developers] 6.0 Zone filling differences

2019-06-21 Thread jp charras
Le 21/06/2019 à 14:57, Seth Hillbrand a écrit : > Hi Wayne- > > I don't think that the relief chamfering is controlled by that option.  > We also don't chamfer the connection on the way into the pad, so I'd > tend to agree with Jeff that the extra corner chamfer on only one side > of the connectio

Re: [Kicad-developers] [Patch] cvpcb Usability Improvements

2019-06-21 Thread Wayne Stambaugh
Ian, I merged your patches into the 5.1 branch. Thanks, Wayne On 6/20/19 6:29 PM, Ian McInerney wrote: > Wayne, > > Here are the rebased patches for 5.1. > > -Ian > > On Thu, Jun 20, 2019 at 10:04 PM Ian McInerney > wrote: > > Wayne, > > Thanks for

Re: [Kicad-developers] 6.0 Zone filling differences

2019-06-21 Thread Jeff Young
Question for you polygon folks: The old algorithm used to add a lot of pads to a “holes” polygon, then did a Simplify() on it, and then a BooleanSubtract() from the filled area. The new code does a Simplify() and BooleanSubtract() per pad. Since the holes are all discrete in either case (ie: n

Re: [Kicad-developers] 6.0 Zone filling differences

2019-06-21 Thread jp charras
Le 21/06/2019 à 17:41, Jeff Young a écrit : > Question for you polygon folks: > > The old algorithm used to add a lot of pads to a “holes” polygon, then did a > Simplify() on it, and then a BooleanSubtract() from the filled area. > > The new code does a Simplify() and BooleanSubtract() per pad.

Re: [Kicad-developers] 6.0 Zone filling differences

2019-06-21 Thread Jeff Young
I’ve pushed new bits. So far these just address the performance issues, not the anomalies. JP, could you give it another run and see if it improves things enough? Cheers, Jeff. > On 21 Jun 2019, at 16:59, jp charras wrote: > > Le 21/06/2019 à 17:41, Jeff Young a écrit : >> Question for you

Re: [Kicad-developers] 6.0 Zone filling differences

2019-06-21 Thread jp charras
Le 21/06/2019 à 19:04, Jeff Young a écrit : > I’ve pushed new bits. So far these just address the performance issues, not > the anomalies. > > JP, could you give it another run and see if it improves things enough? > > Cheers, > Jeff. It improves seriously, but not enough for all boards: The

Re: [Kicad-developers] [PATCH] get initial Python 3 support

2019-06-21 Thread Nick Østergaard
Please try this build: https://kicad-downloads.s3.cern.ch/windows/testing/patched/kicad-patched-390-5.1.2-148-gf0ac61a8f-x86_64.exe It is the 5.1 branch with python3 enabled. On Wed, 19 Jun 2019 at 14:59, mitjan696-ubu...@yahoo.co.uk wrote: > > Hi Nick! > > I am still in the market for 5.1 pytho

Re: [Kicad-developers] 6.0 Zone filling differences

2019-06-21 Thread Jean-Paul Louis
Wayne, Except in very hugh frequency design (higher UHF spectrum, microwaves and millimeter waves) were chamfers can create more problems than they solve. This chamfer should be user optional, the best being individual part layout optional. Just my extra data point, Jean-Paul N1JPL > On Jun

[Kicad-developers] Additional parameters on simulation dialog

2019-06-21 Thread Sylwester Kocjan
Hi, I prepared some changes in KiCad simulation dialog. They are about additional simulation parameters. According to tutorial, which I've found on website, I store them on GitHub repository in branch "Sim_InitialConditions_SK" here: https://github.com/skocjan/kicad_initialconditions.git Could y

[Kicad-developers] LOCALE_IO thread-local

2019-06-21 Thread Seth Hillbrand
Hi Devs- We currently have an RAII locale switch (LOCALE_IO) that swaps the global locale to allow floating point handling with decimal points instead of a commas. Because it changes the global locale, we need to be very careful about allowing the user interface to update during the time tha

[Kicad-developers] VECTOR2I and VECTOR2D

2019-06-21 Thread Reece R. Pollack
A while back, Jeff emailed me a note suggesting that KiCad was trying to decouple from the wxWidgets type wxPoint except where needed in the UI code. He suggested that I should use VECTOR2I instead. I understand and support the desire to decouple from wxWidgets. However, looking at the impleme

Re: [Kicad-developers] VECTOR2I and VECTOR2D

2019-06-21 Thread Reece R. Pollack
Whoops, hit "send" too soon. "Is a simple array" is obviously incorrect. My point was the lack of descriptiveness is a problem. The absence of differentiation between a location and a distance is a missed opportunity. And the abuse of the type as a loosely-related pair of values should be consi