Re: [Kicad-developers] Strange program version numbering in KiCad

[Reece R. Pollack]

On 7/8/19 10:36 PM, Kevin Cozens wrote:

On 2019-07-08 5:10 p.m., Dino Ghilardi wrote:

think about the linux kernel versioning number scheme: even subversion
number means stable release. Odd subversion number means
experimental/development branch.


The kernel used to follow the odd/even numbering scheme but they 
stopped doing that during the 2 series of kernels. It is possible they 
are doing it again. I haven't looked at kernel release numbering in 
quite a few years.


No. That was abandoned years ago, after the release of 2.6, in favor of 
a stream of smaller, incremental steps rather than periodic huge jumps 
that took years to be adopted. The 3.0 release could easily have been 
numbered 2.6.40, being only an incremental change over 2.6.39.


-Reece

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Strange program version numbering in KiCad

[Kevin Cozens]

On 2019-07-08 5:10 p.m., Dino Ghilardi wrote:

think about the linux kernel versioning number scheme: even subversion
number means stable release. Odd subversion number means
experimental/development branch.


The kernel used to follow the odd/even numbering scheme but they stopped 
doing that during the 2 series of kernels. It is possible they are doing it 
again. I haven't looked at kernel release numbering in quite a few years.


--
Cheers!

Kevin.

http://www.ve3syb.ca/   | "Nerds make the shiny things that
https://www.patreon.com/KevinCozens | distract the mouth-breathers, and
| that's why we're powerful"
Owner of Elecraft K2 #2172  |
#include  | --Chris Hardwick

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Strange program version numbering in KiCad

[Kevin Cozens]

On 2019-07-08 4:47 p.m., Nick ??stergaard wrote:

How is a number like 99 being any better than the latest release tag?


The release tag doesn't appear in the title bar of the running program.

--
Cheers!

Kevin.

http://www.ve3syb.ca/   | "Nerds make the shiny things that
https://www.patreon.com/KevinCozens | distract the mouth-breathers, and
| that's why we're powerful"
Owner of Elecraft K2 #2172  |
#include  | --Chris Hardwick

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Strange program version numbering in KiCad

[Eeli Kaikkonen]

ti 9. heinäk. 2019 klo 0.10 Dino Ghilardi (dino.ghila...@ieee.org)
kirjoitti:

> As an alternative to the .99 numbering  (that should work well until 5.98
> stable version is reached (! :-) ) )
>
It was already decided that there won't be even 5.2, let alone 5.98.
Whatever the next stable will include it can be released as 6.0 so there's
no problem.

Eeli Kaikkonen
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Strange program version numbering in KiCad

[Eeli Kaikkonen]

ma 8. heinäk. 2019 klo 23.47 Nick Østergaard (oe.n...@gmail.com) kirjoitti:

> How is a number like 99 being any better than the latest release tag?
>
>
Did you read the original post, about the current problem? What is the
"latest release tag"? 5.1.0 or 5.1.2? Number like 5.99 is unambiguous (and
more clearly points to the next number, 6.0). Like this, my other
suggestions were that the latest or the next release tag wouldn't be used
at all for development versions. The reason is that it would be clear and
unambiguous for all possible purposes.

To add to the original suggestion: -dev ending could be added to make it
even more clear that it's a development version, but can it create problems
for Linux or other package numbering schemes? Probably not, 5.99.0-dev is
smaller than 5.99.1-dev if 5.99-dev would be used for a release candidate.
I wouldn't like using 5.99.0 and then 6.0-rc1 because in alphabetical order
6.0 comes before 6.0-rc1. Therefore 5.99.0, 5.99.1 etc. would be the
easiest and least ambiguous solution.

Eeli Kaikkonen
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Strange program version numbering in KiCad

[Dino Ghilardi]

As an alternative to the .99 numbering  (that should work well until 5.98
stable version is reached (! :-) ) ) also think about the linux kernel
versioning number scheme: even subversion number means stable release. Odd
subversion number means experimental/development branch. At every release
of the "stable" version  also the experimental subversion number is
increased (by two).


Cheers, Dino.





Il Lun 8 Lug 2019 22:48 Nick Østergaard  ha scritto:

> How is a number like 99 being any better than the latest release tag?
>
> On Mon, 8 Jul 2019 at 22:43, Eeli Kaikkonen 
> wrote:
> >
> >
> >
> > ma 8. heinäk. 2019 klo 21.23 Wayne Stambaugh (stambau...@gmail.com)
> kirjoitti:
> >>
> >> Honestly, I don't have a strong preference
> >> one way or another.  If someone can come up with a system that's
> >> workable for everyone, that's fine by me.  I don't have an issue with
> >> using something like 5.99.0.
> >
> >
> > In the user forum we had to explain 6.0 scheme and now we have had to
> explain this 5.1 scheme, although I like the current one better - at least
> it doesn't make people think v6 exists which was certainly worse than the
> confusion about 5.1.0-dev vs. 5.1.2-dev. The more I think about this the
> more convinced I am that a dedicated number for development version would
> be the best and least ambiguous solution. It could be 5.1/stable ->
> 5.2/development -> 6.0/next stable -> 7/next development or 5.1/stable
> 6/development -> 7/next stable, but I guess 5.99 would achieve the same and
> might be even better because 99 is rarely a stable release number. To
> minimize possible packaging problems with rcN vs. plain numbers  the
> release candidates could be numbered 5.99.1 etc. or even 5.99.1-rc1,
> 5.99.2-rc2 etc. That would make the order extremely clear, i.e. there would
> be no question about whether 99-rc1 is before or after 99 either logically
> or in alphabetical or numerical order.
> >
> > Eeli Kaikkonen
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Strange program version numbering in KiCad

[Jeff Young]

My brain can visually parse 5.99.  I have to actually read the current tags and 
think about them before I can figure out what they represent.

> On 8 Jul 2019, at 21:47, Nick Østergaard  wrote:
> 
> How is a number like 99 being any better than the latest release tag?
> 
> On Mon, 8 Jul 2019 at 22:43, Eeli Kaikkonen  wrote:
>> 
>> 
>> 
>> ma 8. heinäk. 2019 klo 21.23 Wayne Stambaugh (stambau...@gmail.com) 
>> kirjoitti:
>>> 
>>> Honestly, I don't have a strong preference
>>> one way or another.  If someone can come up with a system that's
>>> workable for everyone, that's fine by me.  I don't have an issue with
>>> using something like 5.99.0.
>> 
>> 
>> In the user forum we had to explain 6.0 scheme and now we have had to 
>> explain this 5.1 scheme, although I like the current one better - at least 
>> it doesn't make people think v6 exists which was certainly worse than the 
>> confusion about 5.1.0-dev vs. 5.1.2-dev. The more I think about this the 
>> more convinced I am that a dedicated number for development version would be 
>> the best and least ambiguous solution. It could be 5.1/stable -> 
>> 5.2/development -> 6.0/next stable -> 7/next development or 5.1/stable 
>> 6/development -> 7/next stable, but I guess 5.99 would achieve the same and 
>> might be even better because 99 is rarely a stable release number. To 
>> minimize possible packaging problems with rcN vs. plain numbers  the release 
>> candidates could be numbered 5.99.1 etc. or even 5.99.1-rc1, 5.99.2-rc2 etc. 
>> That would make the order extremely clear, i.e. there would be no question 
>> about whether 99-rc1 is before or after 99 either logically or in 
>> alphabetical or numerical order.
>> 
>> Eeli Kaikkonen
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Strange program version numbering in KiCad

[Nick Østergaard]

How is a number like 99 being any better than the latest release tag?

On Mon, 8 Jul 2019 at 22:43, Eeli Kaikkonen  wrote:
>
>
>
> ma 8. heinäk. 2019 klo 21.23 Wayne Stambaugh (stambau...@gmail.com) kirjoitti:
>>
>> Honestly, I don't have a strong preference
>> one way or another.  If someone can come up with a system that's
>> workable for everyone, that's fine by me.  I don't have an issue with
>> using something like 5.99.0.
>
>
> In the user forum we had to explain 6.0 scheme and now we have had to explain 
> this 5.1 scheme, although I like the current one better - at least it doesn't 
> make people think v6 exists which was certainly worse than the confusion 
> about 5.1.0-dev vs. 5.1.2-dev. The more I think about this the more convinced 
> I am that a dedicated number for development version would be the best and 
> least ambiguous solution. It could be 5.1/stable -> 5.2/development -> 
> 6.0/next stable -> 7/next development or 5.1/stable 6/development -> 7/next 
> stable, but I guess 5.99 would achieve the same and might be even better 
> because 99 is rarely a stable release number. To minimize possible packaging 
> problems with rcN vs. plain numbers  the release candidates could be numbered 
> 5.99.1 etc. or even 5.99.1-rc1, 5.99.2-rc2 etc. That would make the order 
> extremely clear, i.e. there would be no question about whether 99-rc1 is 
> before or after 99 either logically or in alphabetical or numerical order.
>
> Eeli Kaikkonen
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Strange program version numbering in KiCad

[Eeli Kaikkonen]

ma 8. heinäk. 2019 klo 21.23 Wayne Stambaugh (stambau...@gmail.com)
kirjoitti:

> Honestly, I don't have a strong preference
> one way or another.  If someone can come up with a system that's
> workable for everyone, that's fine by me.  I don't have an issue with
> using something like 5.99.0.
>

In the user forum we had to explain 6.0 scheme and now we have had to
explain this 5.1 scheme, although I like the current one better - at least
it doesn't make people think v6 exists which was certainly worse than the
confusion about 5.1.0-dev vs. 5.1.2-dev. The more I think about this the
more convinced I am that a dedicated number for development version would
be the best and least ambiguous solution. It could be 5.1/stable ->
5.2/development -> 6.0/next stable -> 7/next development or 5.1/stable
6/development -> 7/next stable, but I guess 5.99 would achieve the same and
might be even better because 99 is rarely a stable release number. To
minimize possible packaging problems with rcN vs. plain numbers  the
release candidates could be numbered 5.99.1 etc. or even 5.99.1-rc1,
5.99.2-rc2 etc. That would make the order extremely clear, i.e. there would
be no question about whether 99-rc1 is before or after 99 either logically
or in alphabetical or numerical order.

Eeli Kaikkonen
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Thermal spoke count

[Andrew Lutsenko]

Maybe there could be "slow" and "fast" mode for spoke (or in general zone)
calculation. Fast for routing, slow for last pass.

On Mon, Jul 8, 2019 at 10:58 AM Jeff Young  wrote:

> Keep in mind that the total width of all the spokes (assuming they’re all
> the same length) doesn’t control the current they’ll carry, only how hot
> they will get for a given current.  Most boards are designed with a huge
> margin of error here.
>
> It’s correct that would *could* do all the calculations automatically
> (both for heat-transfer during soldering and heat-generation during use),
> but it would be *glacially* slow.
>
> Cheers,
> Jeff.
>
> On 8 Jul 2019, at 18:04, Eeli Kaikkonen  wrote:
>
>
>
> ma 8. heinäk. 2019 klo 19.04 Evan Shultz (evan.shu...@gmail.com)
> kirjoitti:
>
>> Because of varying pad shapes, sometimes "+" spokes are best and other
>> times "x" may be preferred. So having a choice of those options, even
>> though both have the same number of thermal spokes, may be desirable. I
>> believe this is captured in the "initial angle" concept, but IMO having the
>> choice of "+", "x", "8 way", and "solid" is more obvious that picking an
>> initial angle. But perhaps I misunderstood.
>>
>
> What I have felt need for is automatically finding locations for spokes so
> that when a pad isn't fully surrounded by a zone it would still be
> connected with 4 (or as many as possible) spokes. Sometimes changing the
> direction between x and + would be enough, sometimes adding spokes from x
> to spokes of +. For example N(orth), NW, W, SW instead of just N and W.
> Because adding spokes is automatic anyways, exact positioning isn't
> important. There should be as much copper as possible (and preferably in
> many directions) while still having the thermal effect. Even the
> thicknesses of the individual spokes could be calculated automatically to
> meet the requirements. What counts is the total width of all the spokes
> together, or am I wrong?
>
> Eeli Kaikkonen
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Zone min-width isn't

[Wayne Stambaugh]

This makes a lot more sense.  I agree that the spoke width should be
allowed to be the same as the minimum copper width.  It just cannot be less.

On 7/8/19 3:30 PM, Jeff Young wrote:
> Ahh, now I understand where I wasn’t clear.  Yes, Seth is correct: I’m trying 
> to allow them to have the same value, not to be the same property.
> 
>> On 8 Jul 2019, at 20:04, Seth Hillbrand  wrote:
>>
>> Hi Wayne-
>>
>> I don't think Jeff is suggesting that the parameters be combined, just that 
>> we should allow the spokes to be the same width as the minimum width.
>>
>> Jeff, is that correct?
>>
>> -Seth
>>
>> On 2019-07-08 09:40, Jeff Young wrote:
>>> We enforce minimum width by deflating the zone by 1/2-min-width,
>>> simplifying the polygons, and then re-inflating by the same amount.
>>> If the spokes are the same width as the minimum, they will disappear.
 On 8 Jul 2019, at 13:57, Wayne Stambaugh  wrote:
 Isn't the thermal spoke width a different setting than the minimum
 width?  I'm under the impression that these two zone properties control
 completely different aspects of the zone fill and have no impact on the
 other.
 On 7/7/2019 5:01 PM, Seth Hillbrand wrote:
> We've done this a few times already with zones.  As long as the existing
> fills don't change, we've left the property.  Refilling is expected to
> change, I think.
> I'd be in favor of allowing min width to mean min width.
> -Seth
> On 2019-07-07 16:08, Jeff Young wrote:
>> We have a zone property “Minimum Width”.  Unfortunately, it isn’t.
>> It’s the width we’ll collapse (so minimum width would be 1nm more).
>> I’d be inclined to fix this (primarily so that thermal spokes and
>> minimum width could be the same), but then we have the old “will
>> change old boards” issue.
>> We could also try and change the property name, but I can’t think of a
>> concise way to express “remove features this width and less”.
>> Thoughts?
>> Cheers,
>> Jeff.
>> Ref: https://bugs.launchpad.net/kicad/+bug/1835674
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Strange program version numbering in KiCad

[Jeff Young]

I find the current scheme confusing.

I like the 5.99 idea….

Cheers,
Jeff.


> On 8 Jul 2019, at 20:03, Wayne Stambaugh  wrote:
> 
> On 7/8/19 2:58 PM, Kevin Cozens wrote:
>> On 2019-07-08 2:38 p.m., Nick ??stergaard wrote:
>>> @Kevin, And the version is not just the tag and number of commits, but
>>> also the sha1.
>> 
>> That is true when reporting bugs. I don't care about the sha1 when I
>> want to make sure I am running the right version of KiCad. That is
>> particularly important now that the file formats are no longer
>> compatible between 5.1 and master.
>> 
> 
> This was the source of confusion for the bug reporter that I mentioned.
> The reporter thought that 5.1.0--gx was older than 5.1.2.
> I can understand the reporters confusion looking just at the version
> numbers.
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Zone min-width isn't

[Jeff Young]

Ahh, now I understand where I wasn’t clear.  Yes, Seth is correct: I’m trying 
to allow them to have the same value, not to be the same property.

> On 8 Jul 2019, at 20:04, Seth Hillbrand  wrote:
> 
> Hi Wayne-
> 
> I don't think Jeff is suggesting that the parameters be combined, just that 
> we should allow the spokes to be the same width as the minimum width.
> 
> Jeff, is that correct?
> 
> -Seth
> 
> On 2019-07-08 09:40, Jeff Young wrote:
>> We enforce minimum width by deflating the zone by 1/2-min-width,
>> simplifying the polygons, and then re-inflating by the same amount.
>> If the spokes are the same width as the minimum, they will disappear.
>>> On 8 Jul 2019, at 13:57, Wayne Stambaugh  wrote:
>>> Isn't the thermal spoke width a different setting than the minimum
>>> width?  I'm under the impression that these two zone properties control
>>> completely different aspects of the zone fill and have no impact on the
>>> other.
>>> On 7/7/2019 5:01 PM, Seth Hillbrand wrote:
 We've done this a few times already with zones.  As long as the existing
 fills don't change, we've left the property.  Refilling is expected to
 change, I think.
 I'd be in favor of allowing min width to mean min width.
 -Seth
 On 2019-07-07 16:08, Jeff Young wrote:
> We have a zone property “Minimum Width”.  Unfortunately, it isn’t.
> It’s the width we’ll collapse (so minimum width would be 1nm more).
> I’d be inclined to fix this (primarily so that thermal spokes and
> minimum width could be the same), but then we have the old “will
> change old boards” issue.
> We could also try and change the property name, but I can’t think of a
> concise way to express “remove features this width and less”.
> Thoughts?
> Cheers,
> Jeff.
> Ref: https://bugs.launchpad.net/kicad/+bug/1835674
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Zone min-width isn't

[Seth Hillbrand]

Hi Wayne-

I don't think Jeff is suggesting that the parameters be combined, just 
that we should allow the spokes to be the same width as the minimum 
width.


Jeff, is that correct?

-Seth

On 2019-07-08 09:40, Jeff Young wrote:

We enforce minimum width by deflating the zone by 1/2-min-width,
simplifying the polygons, and then re-inflating by the same amount.
If the spokes are the same width as the minimum, they will disappear.


On 8 Jul 2019, at 13:57, Wayne Stambaugh  wrote:

Isn't the thermal spoke width a different setting than the minimum
width?  I'm under the impression that these two zone properties 
control
completely different aspects of the zone fill and have no impact on 
the

other.

On 7/7/2019 5:01 PM, Seth Hillbrand wrote:
We've done this a few times already with zones.  As long as the 
existing
fills don't change, we've left the property.  Refilling is expected 
to

change, I think.

I'd be in favor of allowing min width to mean min width.

-Seth

On 2019-07-07 16:08, Jeff Young wrote:

We have a zone property “Minimum Width”.  Unfortunately, it isn’t.
It’s the width we’ll collapse (so minimum width would be 1nm more).

I’d be inclined to fix this (primarily so that thermal spokes and
minimum width could be the same), but then we have the old “will
change old boards” issue.

We could also try and change the property name, but I can’t think of 
a

concise way to express “remove features this width and less”.

Thoughts?

Cheers,
Jeff.

Ref: https://bugs.launchpad.net/kicad/+bug/1835674
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Strange program version numbering in KiCad

[Wayne Stambaugh]

On 7/8/19 2:58 PM, Kevin Cozens wrote:
> On 2019-07-08 2:38 p.m., Nick ??stergaard wrote:
>> @Kevin, And the version is not just the tag and number of commits, but
>> also the sha1.
> 
> That is true when reporting bugs. I don't care about the sha1 when I
> want to make sure I am running the right version of KiCad. That is
> particularly important now that the file formats are no longer
> compatible between 5.1 and master.
> 

This was the source of confusion for the bug reporter that I mentioned.
 The reporter thought that 5.1.0--gx was older than 5.1.2.
I can understand the reporters confusion looking just at the version
numbers.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Strange program version numbering in KiCad

[Kevin Cozens]

On 2019-07-08 2:38 p.m., Nick ??stergaard wrote:

@Kevin, And the version is not just the tag and number of commits, but
also the sha1.


That is true when reporting bugs. I don't care about the sha1 when I want to 
make sure I am running the right version of KiCad. That is particularly 
important now that the file formats are no longer compatible between 5.1 and 
master.


--
Cheers!

Kevin.

http://www.ve3syb.ca/   | "Nerds make the shiny things that
https://www.patreon.com/KevinCozens | distract the mouth-breathers, and
| that's why we're powerful"
Owner of Elecraft K2 #2172  |
#include  | --Chris Hardwick

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Strange program version numbering in KiCad

[Nick Østergaard]

@Wayne I think the current one is fine.

@Kevin, And the version is not just the tag and number of commits, but
also the sha1.

On Mon, 8 Jul 2019 at 20:23, Wayne Stambaugh  wrote:
>
> It used to be 6.0.0-dev but apparently this caused package version
> issues so it was dropped in favor of the current version tagging scheme.
>  There has already been at least one confused bug reporter about the
> current versioning scheme.  Honestly, I don't have a strong preference
> one way or another.  If someone can come up with a system that's
> workable for everyone, that's fine by me.  I don't have an issue with
> using something like 5.99.0.
>
> Cheers,
>
> Wayne
>
> On 7/8/2019 1:45 PM, Kevin Cozens wrote:
> > Greetings, all.
> >
> > I just ran across something odd with the version number shown by the
> > KiCad program(s).
> >
> > I compiled and installed git master. When I ran it the version number
> > reported is 5.1.0.1195. As I also compile and run the 5.1 version I
> > thought I had a mix up when I did the compile. When I checked my 5.1
> > install it has 5.1.2.109 as the version number.
> >
> > I would expect git master to report a version number higher than the 5.1
> > branch. Perhaps 5.2, or even as high as 5.9 as it is going to be
> > released as 6 something, IIRC.
> >
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Strange program version numbering in KiCad

[Wayne Stambaugh]

It used to be 6.0.0-dev but apparently this caused package version
issues so it was dropped in favor of the current version tagging scheme.
 There has already been at least one confused bug reporter about the
current versioning scheme.  Honestly, I don't have a strong preference
one way or another.  If someone can come up with a system that's
workable for everyone, that's fine by me.  I don't have an issue with
using something like 5.99.0.

Cheers,

Wayne

On 7/8/2019 1:45 PM, Kevin Cozens wrote:
> Greetings, all.
> 
> I just ran across something odd with the version number shown by the
> KiCad program(s).
> 
> I compiled and installed git master. When I ran it the version number
> reported is 5.1.0.1195. As I also compile and run the 5.1 version I
> thought I had a mix up when I did the compile. When I checked my 5.1
> install it has 5.1.2.109 as the version number.
> 
> I would expect git master to report a version number higher than the 5.1
> branch. Perhaps 5.2, or even as high as 5.9 as it is going to be
> released as 6 something, IIRC.
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Strange program version numbering in KiCad

[Kevin Cozens]

Greetings, all.

I just ran across something odd with the version number shown by the KiCad 
program(s).


I compiled and installed git master. When I ran it the version number 
reported is 5.1.0.1195. As I also compile and run the 5.1 version I thought 
I had a mix up when I did the compile. When I checked my 5.1 install it has 
5.1.2.109 as the version number.


I would expect git master to report a version number higher than the 5.1 
branch. Perhaps 5.2, or even as high as 5.9 as it is going to be released as 
6 something, IIRC.


--
Cheers!

Kevin.

http://www.ve3syb.ca/   | "Nerds make the shiny things that
https://www.patreon.com/KevinCozens | distract the mouth-breathers, and
| that's why we're powerful"
Owner of Elecraft K2 #2172  |
#include  | --Chris Hardwick

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Thermal spoke count

[Jeff Young]

Keep in mind that the total width of all the spokes (assuming they’re all the 
same length) doesn’t control the current they’ll carry, only how hot they will 
get for a given current.  Most boards are designed with a huge margin of error 
here.

It’s correct that would could do all the calculations automatically (both for 
heat-transfer during soldering and heat-generation during use), but it would be 
glacially slow.

Cheers,
Jeff.

> On 8 Jul 2019, at 18:04, Eeli Kaikkonen  wrote:
> 
> 
> 
> ma 8. heinäk. 2019 klo 19.04 Evan Shultz (evan.shu...@gmail.com 
> ) kirjoitti:
> Because of varying pad shapes, sometimes "+" spokes are best and other times 
> "x" may be preferred. So having a choice of those options, even though both 
> have the same number of thermal spokes, may be desirable. I believe this is 
> captured in the "initial angle" concept, but IMO having the choice of "+", 
> "x", "8 way", and "solid" is more obvious that picking an initial angle. But 
> perhaps I misunderstood.
> 
> What I have felt need for is automatically finding locations for spokes so 
> that when a pad isn't fully surrounded by a zone it would still be connected 
> with 4 (or as many as possible) spokes. Sometimes changing the direction 
> between x and + would be enough, sometimes adding spokes from x to spokes of 
> +. For example N(orth), NW, W, SW instead of just N and W.  Because adding 
> spokes is automatic anyways, exact positioning isn't important. There should 
> be as much copper as possible (and preferably in many directions) while still 
> having the thermal effect. Even the thicknesses of the individual spokes 
> could be calculated automatically to meet the requirements. What counts is 
> the total width of all the spokes together, or am I wrong?
> 
> Eeli Kaikkonen
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] How often do we want to auto-fill zones?

[Jeff Young]

When I’m focusing on one thing it’s distracting when the screen is updating 
elsewhere.

> On 8 Jul 2019, at 14:01, Eeli Kaikkonen  wrote:
> 
> 
> 
> la 6. heinäk. 2019 klo 15.17 Jeff Young (j...@rokeby.ie 
> ) kirjoitti:
>  Refilling on each move (even when fills are fast) is pretty noisy.
> 
> What do you mean by "noisy"?
> 
> Eeli Kaikkonen
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Thermal spoke count

[Eeli Kaikkonen]

ma 8. heinäk. 2019 klo 19.04 Evan Shultz (evan.shu...@gmail.com) kirjoitti:

> Because of varying pad shapes, sometimes "+" spokes are best and other
> times "x" may be preferred. So having a choice of those options, even
> though both have the same number of thermal spokes, may be desirable. I
> believe this is captured in the "initial angle" concept, but IMO having the
> choice of "+", "x", "8 way", and "solid" is more obvious that picking an
> initial angle. But perhaps I misunderstood.
>

What I have felt need for is automatically finding locations for spokes so
that when a pad isn't fully surrounded by a zone it would still be
connected with 4 (or as many as possible) spokes. Sometimes changing the
direction between x and + would be enough, sometimes adding spokes from x
to spokes of +. For example N(orth), NW, W, SW instead of just N and W.
Because adding spokes is automatic anyways, exact positioning isn't
important. There should be as much copper as possible (and preferably in
many directions) while still having the thermal effect. Even the
thicknesses of the individual spokes could be calculated automatically to
meet the requirements. What counts is the total width of all the spokes
together, or am I wrong?

Eeli Kaikkonen
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Thermal spoke count

[Jeff Young]

Hi Evan,

> On 8 Jul 2019, at 17:04, Evan Shultz  wrote:
> 
> Apologies in advance for what will probably be a long message...
> 
> Would 8-way spokes be possible to implement "quickly" (in the algorithmic 
> sense, not the time to implement sense)? (I don't know if the shortcut you've 
> (Jeff) devised works for a paired set of 4 thermal spokes.) 8-way thermals 
> can be quite useful where there is a tough balance between connection 
> "strength" for current but also a requirement for thermal relief during 
> soldering.

8 cannot be done “fast”, although both “+” and “x” can (we do that by rotating 
for the calculations and then rotating back).  

> 
> Because of varying pad shapes, sometimes "+" spokes are best and other times 
> "x" may be preferred. So having a choice of those options, even though both 
> have the same number of thermal spokes, may be desirable. I believe this is 
> captured in the "initial angle" concept, but IMO having the choice of "+", 
> "x", "8 way", and "solid" is more obvious that picking an initial angle. But 
> perhaps I misunderstood.

Right now we do “x” on circular pads and “+” on everything else.

> 
> What about if some spokes can't be connected because the pad is near a zone 
> edge? Would a "+" connection lop off the rightmost spoke, for example, 
> leaving the other three? Is there a way to set a minimum number of spokes? Or 
> to force the fourth spoke to move to another location around the pad so that 
> the specified number of spokes are always present?

Currently spokes never move, but they are lopped off if they don’t reach the 
zone.

> 
> Over the years I've made good use of a hierarchy of thermal spoke properties:
> - Board (default for new zones on the board)
> - Per-zone properties
> - Per-pad properties
> 
> As Seth said, SMD, THT, and vias all may need different connection types. The 
> "relief for PTHs only" option is usually OK, but having discrete options for 
> all pad types that can be connected to the zone does have some benefit at 
> times. Not often, as mentioned, so somewhat burying these options is probably 
> OK. I usually find these options powerful when I have one large zone touching 
> many parts; a patchwork of many zones might also work but is usually a bigger 
> hassle in the long run.
> 
> In addition, sometimes I want to manually control the zone connection so 
> having a per-pin option for "none", that creates a ratsnest until I manually 
> add a track for connection, is a valuable choice as well.
> 
> Each layer (or at least top, inner, and bottom) may benefit from a unique 
> connection type. For example, for large leads or parts that absorb heat (like 
> a THT power inductor) I can often use solid  zone connection on the bottom as 
> that layer will touch the solder wave. But on other layers, I need thermal 
> relief to allow for acceptable barrel fill.
> 
> Those three pad types above may also benefit from unique clearance settings 
> instead of only a single per-zone clearance. If I can set additional 
> clearance for a single pad, and better still if I can adjust that clearance 
> per-layer, I can often improve solderability.
> 
> That's a huge matrix of options but they are all valid and valuable in some 
> circumstances (whether the user knows how to drive the tool or not). I see no 
> other way than to make all of this possible in other to best balance 
> electrical and thermal/manufacturing desires. I know it can be beneficial. 
> Surely there's a reasonable cadence of implementation and release, should all 
> of this be eventually added to KiCad.

He he.  I had trouble parsing that last sentence; I kept reading “Cadence” as 
the company.

Cheers,
Jeff



> 
> On Mon, Jul 8, 2019 at 5:59 AM Seth Hillbrand  > wrote:
> On 2019-07-08 08:15, Jeff Young wrote:
> > To support it we’d need to add count (and probably initial angle) to
> > the zone properties dialog, the footprint’s local clearance and
> > spacing seciton and the pad’s local clearance and spacing section.  So
> > it would complicate the GUI (although the second and third of those
> > are at least on a seldom-used tab).
> 
> If we decide to implement this, I'd like to also have an optional 
> "suppress instances" list so that if for some reason the auto placement 
> of spokes on a custom shape didn't work, I could remove the unwanted 
> spokes.
> 
> But I think that these properties should not go in the zones, only in 
> the footprint and pads as it is sufficiently outre that it is unlikely 
> to find much use in the general setting.
> 
> The properties that may be useful in the zones settings would be spoke 
> defaults for SMD, through-hole and vias.  These might be addressable by 
> placing an ellipsis button after the Pad Connections drop down that 
> brings up an advanced dialog setting.
> 
> This is pure spitballing however.
> 
> -S
> 
> ___
> Mailing list: 

Re: [Kicad-developers] Thermal spoke count

[Evan Shultz]

Apologies in advance for what will probably be a long message...

Would 8-way spokes be possible to implement "quickly" (in the algorithmic
sense, not the time to implement sense)? (I don't know if the shortcut
you've (Jeff) devised works for a paired set of 4 thermal spokes.) 8-way
thermals can be quite useful where there is a tough balance between
connection "strength" for current but also a requirement for thermal relief
during soldering.

Because of varying pad shapes, sometimes "+" spokes are best and other
times "x" may be preferred. So having a choice of those options, even
though both have the same number of thermal spokes, may be desirable. I
believe this is captured in the "initial angle" concept, but IMO having the
choice of "+", "x", "8 way", and "solid" is more obvious that picking an
initial angle. But perhaps I misunderstood.

What about if some spokes can't be connected because the pad is near a zone
edge? Would a "+" connection lop off the rightmost spoke, for example,
leaving the other three? Is there a way to set a minimum number of spokes?
Or to force the fourth spoke to move to another location around the pad so
that the specified number of spokes are always present?

Over the years I've made good use of a hierarchy of thermal spoke
properties:
- Board (default for new zones on the board)
- Per-zone properties
- Per-pad properties

As Seth said, SMD, THT, and vias all may need different connection types.
The "relief for PTHs only" option is usually OK, but having discrete
options for all pad types that can be connected to the zone does have some
benefit at times. Not often, as mentioned, so somewhat burying these
options is probably OK. I usually find these options powerful when I have
one large zone touching many parts; a patchwork of many zones might also
work but is usually a bigger hassle in the long run.

In addition, sometimes I want to manually control the zone connection so
having a per-pin option for "none", that creates a ratsnest until I
manually add a track for connection, is a valuable choice as well.

Each layer (or at least top, inner, and bottom) may benefit from a unique
connection type. For example, for large leads or parts that absorb heat
(like a THT power inductor) I can often use solid  zone connection on the
bottom as that layer will touch the solder wave. But on other layers, I
need thermal relief to allow for acceptable barrel fill.

Those three pad types above may also benefit from unique clearance settings
instead of only a single per-zone clearance. If I can set additional
clearance for a single pad, and better still if I can adjust that clearance
per-layer, I can often improve solderability.

That's a huge matrix of options but they are all valid and valuable in some
circumstances (whether the user knows how to drive the tool or not). I see
no other way than to make all of this possible in other to best balance
electrical and thermal/manufacturing desires. I know it can be beneficial.
Surely there's a reasonable cadence of implementation and release, should
all of this be eventually added to KiCad.

On Mon, Jul 8, 2019 at 5:59 AM Seth Hillbrand  wrote:

> On 2019-07-08 08:15, Jeff Young wrote:
> > To support it we’d need to add count (and probably initial angle) to
> > the zone properties dialog, the footprint’s local clearance and
> > spacing seciton and the pad’s local clearance and spacing section.  So
> > it would complicate the GUI (although the second and third of those
> > are at least on a seldom-used tab).
>
> If we decide to implement this, I'd like to also have an optional
> "suppress instances" list so that if for some reason the auto placement
> of spokes on a custom shape didn't work, I could remove the unwanted
> spokes.
>
> But I think that these properties should not go in the zones, only in
> the footprint and pads as it is sufficiently outre that it is unlikely
> to find much use in the general setting.
>
> The properties that may be useful in the zones settings would be spoke
> defaults for SMD, through-hole and vias.  These might be addressable by
> placing an ellipsis button after the Pad Connections drop down that
> brings up an advanced dialog setting.
>
> This is pure spitballing however.
>
> -S
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Zone min-width isn't

[Jeff Young]

We enforce minimum width by deflating the zone by 1/2-min-width, simplifying 
the polygons, and then re-inflating by the same amount.  If the spokes are the 
same width as the minimum, they will disappear.

> On 8 Jul 2019, at 13:57, Wayne Stambaugh  wrote:
> 
> Isn't the thermal spoke width a different setting than the minimum
> width?  I'm under the impression that these two zone properties control
> completely different aspects of the zone fill and have no impact on the
> other.
> 
> On 7/7/2019 5:01 PM, Seth Hillbrand wrote:
>> We've done this a few times already with zones.  As long as the existing
>> fills don't change, we've left the property.  Refilling is expected to
>> change, I think.
>> 
>> I'd be in favor of allowing min width to mean min width.
>> 
>> -Seth
>> 
>> On 2019-07-07 16:08, Jeff Young wrote:
>>> We have a zone property “Minimum Width”.  Unfortunately, it isn’t.
>>> It’s the width we’ll collapse (so minimum width would be 1nm more).
>>> 
>>> I’d be inclined to fix this (primarily so that thermal spokes and
>>> minimum width could be the same), but then we have the old “will
>>> change old boards” issue.
>>> 
>>> We could also try and change the property name, but I can’t think of a
>>> concise way to express “remove features this width and less”.
>>> 
>>> Thoughts?
>>> 
>>> Cheers,
>>> Jeff.
>>> 
>>> Ref: https://bugs.launchpad.net/kicad/+bug/1835674
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>> 
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] How often do we want to auto-fill zones?

[Eeli Kaikkonen]

la 6. heinäk. 2019 klo 15.17 Jeff Young (j...@rokeby.ie) kirjoitti:

>  Refilling on each move (even when fills are fast) is pretty noisy.
>

What do you mean by "noisy"?

Eeli Kaikkonen
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Thermal spoke count

[Seth Hillbrand]

On 2019-07-08 08:15, Jeff Young wrote:

To support it we’d need to add count (and probably initial angle) to
the zone properties dialog, the footprint’s local clearance and
spacing seciton and the pad’s local clearance and spacing section.  So
it would complicate the GUI (although the second and third of those
are at least on a seldom-used tab).


If we decide to implement this, I'd like to also have an optional 
"suppress instances" list so that if for some reason the auto placement 
of spokes on a custom shape didn't work, I could remove the unwanted 
spokes.


But I think that these properties should not go in the zones, only in 
the footprint and pads as it is sufficiently outre that it is unlikely 
to find much use in the general setting.


The properties that may be useful in the zones settings would be spoke 
defaults for SMD, through-hole and vias.  These might be addressable by 
placing an ellipsis button after the Pad Connections drop down that 
brings up an advanced dialog setting.


This is pure spitballing however.

-S

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Zone min-width isn't

[Wayne Stambaugh]

Isn't the thermal spoke width a different setting than the minimum
width?  I'm under the impression that these two zone properties control
completely different aspects of the zone fill and have no impact on the
other.

On 7/7/2019 5:01 PM, Seth Hillbrand wrote:
> We've done this a few times already with zones.  As long as the existing
> fills don't change, we've left the property.  Refilling is expected to
> change, I think.
> 
> I'd be in favor of allowing min width to mean min width.
> 
> -Seth
> 
> On 2019-07-07 16:08, Jeff Young wrote:
>> We have a zone property “Minimum Width”.  Unfortunately, it isn’t.
>> It’s the width we’ll collapse (so minimum width would be 1nm more).
>>
>> I’d be inclined to fix this (primarily so that thermal spokes and
>> minimum width could be the same), but then we have the old “will
>> change old boards” issue.
>>
>> We could also try and change the property name, but I can’t think of a
>> concise way to express “remove features this width and less”.
>>
>> Thoughts?
>>
>> Cheers,
>> Jeff.
>>
>> Ref: https://bugs.launchpad.net/kicad/+bug/1835674
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Thermal spoke count

[Jeff Young]

The new zone filling algorithm can support additional spoke counts, though 
they’ll be much slower than 4 (as we can’t cheat some of the math by relying on 
cartesian coordinates).

To support it we’d need to add count (and probably initial angle) to the zone 
properties dialog, the footprint’s local clearance and spacing seciton and the 
pad’s local clearance and spacing section.  So it would complicate the GUI 
(although the second and third of those are at least on a seldom-used tab).

So, is it useful enough to put in 6.0, or should we put it on the back burner?
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Last commit not compiling.

[Nick Østergaard]

Please see
https://bugs.launchpad.net/kicad/+bug/1835408/comments/3

I think this is the same issue. Do a clean build.

On Mon, 8 Jul 2019 at 14:01, Dino Ghilardi  wrote:
>
> commit 4852c91b423abf1e3e745f9d17ad56c92d5445b8
>
> does not compile for me on Linux, even re-generating config files with
> cmake.
>
> Does anybody else have the same issue?
>
> The missing definitions seems to be in pcb_lexer.h, but this is not
> included in pcb-parser.cpp. Should it?
>
>
> When "make -j7" fails I get:
>
>
> /home/dinoghi/SANDBOXKICAD5/src/kicad/pcbnew/pcb_parser.cpp: In member
> function ‘void PCB_PARSER::parseSetup()’:
> /home/dinoghi/SANDBOXKICAD5/src/kicad/pcbnew/pcb_parser.cpp:1278:14:
> error: ‘T_user_diff_pair’ was not declared in this scope
>   case T_user_diff_pair:
>^~~~
> /home/dinoghi/SANDBOXKICAD5/src/kicad/pcbnew/pcb_parser.cpp:1325:14:
> error: ‘T_defaults’ was not declared in this scope
>   case T_defaults:
>^~
> /home/dinoghi/SANDBOXKICAD5/src/kicad/pcbnew/pcb_parser.cpp: In member
> function ‘void PCB_PARSER::parseDefaults(BOARD_DESIGN_SETTINGS&)’:
> /home/dinoghi/SANDBOXKICAD5/src/kicad/pcbnew/pcb_parser.cpp:1440:14:
> error: ‘T_edge_clearance’ was not declared in this scope
>   case T_edge_clearance:
>^~~~
> /home/dinoghi/SANDBOXKICAD5/src/kicad/pcbnew/pcb_parser.cpp:1445:14:
> error: ‘T_copper_line_width’ was not declared in this scope
>   case T_copper_line_width:
>^~~
> /home/dinoghi/SANDBOXKICAD5/src/kicad/pcbnew/pcb_parser.cpp:1450:14:
> error: ‘T_copper_text_dims’ was not declared in this scope
>   case T_copper_text_dims:
>^~
> /home/dinoghi/SANDBOXKICAD5/src/kicad/pcbnew/pcb_parser.cpp:1454:14:
> error: ‘T_courtyard_line_width’ was not declared in this scope
>   case T_courtyard_line_width:
>^~
> /home/dinoghi/SANDBOXKICAD5/src/kicad/pcbnew/pcb_parser.cpp:1459:14:
> error: ‘T_edge_cuts_line_width’ was not declared in this scope
>   case T_edge_cuts_line_width:
>^~
> /home/dinoghi/SANDBOXKICAD5/src/kicad/pcbnew/pcb_parser.cpp:1464:14:
> error: ‘T_silk_line_width’ was not declared in this scope
>   case T_silk_line_width:
>^
> /home/dinoghi/SANDBOXKICAD5/src/kicad/pcbnew/pcb_parser.cpp:1469:14:
> error: ‘T_silk_text_dims’ was not declared in this scope
>   case T_silk_text_dims:
>^~~~
> /home/dinoghi/SANDBOXKICAD5/src/kicad/pcbnew/pcb_parser.cpp:1473:14:
> error: ‘T_other_layers_line_width’ was not declared in this scope
>   case T_other_layers_line_width:
>^
> /home/dinoghi/SANDBOXKICAD5/src/kicad/pcbnew/pcb_parser.cpp:1478:14:
> error: ‘T_other_layers_text_dims’ was not declared in this scope
>   case T_other_layers_text_dims:
>^~~~
> /home/dinoghi/SANDBOXKICAD5/src/kicad/pcbnew/pcb_parser.cpp: In member
> function ‘void PCB_PARSER::parseDefaultTextDims(BOARD_DESIGN_SETTINGS&,
> int)’:
> /home/dinoghi/SANDBOXKICAD5/src/kicad/pcbnew/pcb_parser.cpp:1515:14:
> error: ‘T_keep_upright’ was not declared in this scope
>   case T_keep_upright:
>
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Last commit not compiling.

[Dino Ghilardi]

commit 4852c91b423abf1e3e745f9d17ad56c92d5445b8

does not compile for me on Linux, even re-generating config files with 
cmake.


Does anybody else have the same issue?

The missing definitions seems to be in pcb_lexer.h, but this is not 
included in pcb-parser.cpp. Should it?



When "make -j7" fails I get:


/home/dinoghi/SANDBOXKICAD5/src/kicad/pcbnew/pcb_parser.cpp: In member 
function ‘void PCB_PARSER::parseSetup()’:
/home/dinoghi/SANDBOXKICAD5/src/kicad/pcbnew/pcb_parser.cpp:1278:14: 
error: ‘T_user_diff_pair’ was not declared in this scope

 case T_user_diff_pair:
  ^~~~
/home/dinoghi/SANDBOXKICAD5/src/kicad/pcbnew/pcb_parser.cpp:1325:14: 
error: ‘T_defaults’ was not declared in this scope

 case T_defaults:
  ^~
/home/dinoghi/SANDBOXKICAD5/src/kicad/pcbnew/pcb_parser.cpp: In member 
function ‘void PCB_PARSER::parseDefaults(BOARD_DESIGN_SETTINGS&)’:
/home/dinoghi/SANDBOXKICAD5/src/kicad/pcbnew/pcb_parser.cpp:1440:14: 
error: ‘T_edge_clearance’ was not declared in this scope

 case T_edge_clearance:
  ^~~~
/home/dinoghi/SANDBOXKICAD5/src/kicad/pcbnew/pcb_parser.cpp:1445:14: 
error: ‘T_copper_line_width’ was not declared in this scope

 case T_copper_line_width:
  ^~~
/home/dinoghi/SANDBOXKICAD5/src/kicad/pcbnew/pcb_parser.cpp:1450:14: 
error: ‘T_copper_text_dims’ was not declared in this scope

 case T_copper_text_dims:
  ^~
/home/dinoghi/SANDBOXKICAD5/src/kicad/pcbnew/pcb_parser.cpp:1454:14: 
error: ‘T_courtyard_line_width’ was not declared in this scope

 case T_courtyard_line_width:
  ^~
/home/dinoghi/SANDBOXKICAD5/src/kicad/pcbnew/pcb_parser.cpp:1459:14: 
error: ‘T_edge_cuts_line_width’ was not declared in this scope

 case T_edge_cuts_line_width:
  ^~
/home/dinoghi/SANDBOXKICAD5/src/kicad/pcbnew/pcb_parser.cpp:1464:14: 
error: ‘T_silk_line_width’ was not declared in this scope

 case T_silk_line_width:
  ^
/home/dinoghi/SANDBOXKICAD5/src/kicad/pcbnew/pcb_parser.cpp:1469:14: 
error: ‘T_silk_text_dims’ was not declared in this scope

 case T_silk_text_dims:
  ^~~~
/home/dinoghi/SANDBOXKICAD5/src/kicad/pcbnew/pcb_parser.cpp:1473:14: 
error: ‘T_other_layers_line_width’ was not declared in this scope

 case T_other_layers_line_width:
  ^
/home/dinoghi/SANDBOXKICAD5/src/kicad/pcbnew/pcb_parser.cpp:1478:14: 
error: ‘T_other_layers_text_dims’ was not declared in this scope

 case T_other_layers_text_dims:
  ^~~~
/home/dinoghi/SANDBOXKICAD5/src/kicad/pcbnew/pcb_parser.cpp: In member 
function ‘void PCB_PARSER::parseDefaultTextDims(BOARD_DESIGN_SETTINGS&, 
int)’:
/home/dinoghi/SANDBOXKICAD5/src/kicad/pcbnew/pcb_parser.cpp:1515:14: 
error: ‘T_keep_upright’ was not declared in this scope

 case T_keep_upright:



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] [PATCH] Board statistics dialog

[Jeff Young]

Hi Alex,

I don’t like the top-side/bottom-side checkboxes (because I want to see both 
numbers at once), but I do like the other three.

I think we need to move to a list or grid presentation, though.  One of the 
other features we’ve talked about is user-defined attributes, so there might be 
more things than just THT, SMD and Virtual.

Cheers,
Jeff.

[1] https://bugs.launchpad.net/kicad/+bug/1789363 

[2] https://bugs.launchpad.net/kicad/+bug/980919 
 



> On 8 Jul 2019, at 11:20, Alexander Shuklin  wrote:
> 
> Hi!, I added stuff for footprints THT,SMD,virtual properties and now it's 
> calculate area.
> But for me dialog is not very straight forward now. Can you please advice, 
> what better to do?
> I attached 2 pics. I think, maybe right way is to add few checkboxes which 
> will change dialog data as soon as you pressed them?
> Just look at pics and say what would be better, as I'm in doubt.
> Second one is in WxFormBuilder so it looks a bit different.
> 
> 
> Пятница, 5 июля 2019, 0:05 +03:00 от Jeff Young :
> 
> I agree that it shouldn’t be its own tool, but PCB_EDITOR_CONTROL is getting 
> too big.
> 
> Let’s just name this tool the PCB_INSPECTION_TOOL, and then I’ll move the 
> highlight and list nets stuff, and the DRC dialog to it later.  That’ll 
> nicely parallel the EE_INSPECTION_TOOL.
> 
> Cheers,
> Jeff.
> 
>> On 4 Jul 2019, at 21:56, Ian McInerney > > wrote:
>> 
>> This looks nice, but a few comments from my initial usage of it:
>> 
>> Usability:
>> 1) When I use english units, your statistics dialog gives the dimensions in 
>> mils. It should probably give those in inches instead, since that is what 
>> the grid panel at the bottom gives.
>> 2) Including the board area would also be useful, definitely the area of the 
>> bounding box, and possibly the area of the actual PCB (but that is more 
>> complicated). I know of several board houses that charge based on area, so 
>> this could provide a quick way to estimate price for the user.
>> 3) I am not sure I am a fan of the icon used for the menu item, since this 
>> dialog focuses on board statistics rather than footprint statistics and that 
>> icon is used mainly for footprint actions. Could a variant of the pcbnew 
>> icon be used?
>> 
>> 
>> While the code as you gave works, I think the following changes could be 
>> beneficial:
>> 1) It seems that this action could just be added to PCB_EDITOR_CONTROL as 
>> the action "pcbnew.Control.BoardStatistics" rather than creating a new tool 
>> just for this.
>> 2) I think the launching of the window could be simplified if you used a 
>> modal window instead (see https://docs.wxwidgets.org/3.0/classwx_dialog.html 
>> , the Modal and Modeless 
>> section). Then you don't have to keep track of the window pointer, and could 
>> actually just make launching this a single function instead of an entire 
>> class (this would go nicely with point #1).
>> 3) The function to start the window should be TransferDataToWindow, not 
>> TransferDataFromWindow. FromWindow is called when the window is destroyed 
>> and ToWindow is called when it is created. Also, it is called automatically 
>> when the window is started, so there is no need to manually call it.
>> 
>> 
>> Other code parts:
>> 1) There are some lines that are too long in dialog_board_statistics.cpp 
>> (max 100 characters per line)
>> 2) There are a few whitespace errors when applying it:
>> Applying: added board statistics dialog, which shows info for production and 
>> assembly
>> /home/imcinerney/Downloads/0001-added-board-statistics-dialog-which-shows-info-for-p.patch:158:
>>  trailing whitespace.
>> /* if pin has drill with width==0 and height==0, we 
>> /home/imcinerney/Downloads/0001-added-board-statistics-dialog-which-shows-info-for-p.patch:1612:
>>  new blank line at EOF.
>> +
>> warning: 2 lines add whitespace errors.
>> 
>> Overall though it looks pretty nice.
>> 
>> -Ian
>> 
>> On Thu, Jul 4, 2019 at 3:07 PM Шуклин Александр > > wrote:
>> Hi, that's first time I try to contribute to KiCad and write to Launchpad 
>> mailing lists, so please, don't beat me to hard )))
>> I really miss some board statistic dialog, where you can see quantity of SMD 
>> pads, THT pads, board dimensions, all the stuff, you need for PCB production 
>> and assembly. There was also issue in the bug tracker 
>> https://bugs.launchpad.net/kicad/+bug/1817232 
>> 
>> And like guy from bug issue, I moved from Altium Designer and miss that 
>> dialog as well. 
>> Can you please look at that and commit if you think it's useful or tell me 
>> what to change.
>> That's my commit in the github:
>> https://github.com/jasuramme/kicad-source-mirror/commit/6290375c1d41ddb89d4b08067593f170c7d344c5
>>  
>> 

Re: [Kicad-developers] [PATCH] Board statistics dialog

[Alexander Shuklin]

Hi!, I added stuff for footprints THT,SMD,virtual properties and now it's 
calculate area.
But for me dialog is not very straight forward now. Can you please advice, what 
better to do?
I attached 2 pics. I think, maybe right way is to add few checkboxes which will 
change dialog data as soon as you pressed them?
Just look at pics and say what would be better, as I'm in doubt.
Second one is in WxFormBuilder so it looks a bit different.


>Пятница,  5 июля 2019, 0:05 +03:00 от Jeff Young :
>
>I agree that it shouldn’t be its own tool, but PCB_EDITOR_CONTROL is getting 
>too big.
>
>Let’s just name this tool the PCB_INSPECTION_TOOL, and then I’ll move the 
>highlight and list nets stuff, and the DRC dialog to it later.  That’ll nicely 
>parallel the EE_INSPECTION_TOOL.
>
>Cheers,
>Jeff.
>
>>On 4 Jul 2019, at 21:56, Ian McInerney < ian.s.mciner...@ieee.org > wrote:
>>This looks nice, but a few comments from my initial usage of it:
>>
>>Usability:
>>1) When I use english units, your statistics dialog gives the dimensions in 
>>mils. It should probably give those in inches instead, since that is what the 
>>grid panel at the bottom gives.
>>2) Including the board area would also be useful, definitely the area of the 
>>bounding box, and possibly the area of the actual PCB (but that is more 
>>complicated). I know of several board houses that charge based on area, so 
>>this could provide a quick way to estimate price for the user.
>>3) I am not sure I am a fan of the icon used for the menu item, since this 
>>dialog focuses on board statistics rather than footprint statistics and that 
>>icon is used mainly for footprint actions. Could a variant of the pcbnew icon 
>>be used?
>>
>>
>>While the code as you gave works, I think the following changes could be 
>>beneficial:
>>1) It seems that this action could just be added to PCB_EDITOR_CONTROL as the 
>>action "pcbnew.Control.BoardStatistics" rather than creating a new tool just 
>>for this.
>>2) I think the launching of the window could be simplified if you used a 
>>modal window instead (see  https://docs.wxwidgets.org/3.0/classwx_dialog.html 
>>, the Modal and Modeless section). Then you don't have to keep track of the 
>>window pointer, and could actually just make launching this a single function 
>>instead of an entire class (this would go nicely with point #1).
>>3) The function to start the window should be TransferDataToWindow, not 
>>TransferDataFromWindow. FromWindow is called when the window is destroyed and 
>>ToWindow is called when it is created. Also, it is called automatically when 
>>the window is started, so there is no need to manually call it.
>>
>>
>>Other code parts:
>>1) There are some lines that are too long in dialog_board_statistics.cpp (max 
>>100 characters per line)
>>2) There are a few whitespace errors when applying it:
>>Applying: added board statistics dialog, which shows info for production and 
>>assembly
>>/home/imcinerney/Downloads/0001-added-board-statistics-dialog-which-shows-info-for-p.patch:158:
>> trailing whitespace.
>>                /* if pin has drill with width==0 and height==0, we 
>>/home/imcinerney/Downloads/0001-added-board-statistics-dialog-which-shows-info-for-p.patch:1612:
>> new blank line at EOF.
>>+
>>warning: 2 lines add whitespace errors.
>>
>>Overall though it looks pretty nice.
>>
>>-Ian
>>On Thu, Jul 4, 2019 at 3:07 PM Шуклин Александр < jasura...@mail.ru > wrote:
>>>Hi, that's first time I try to contribute to KiCad and write to Launchpad 
>>>mailing lists, so please, don't beat me to hard )))
>>>I really miss some board statistic dialog, where you can see quantity of SMD 
>>>pads, THT pads, board dimensions, all the stuff, you need for PCB production 
>>>and assembly. There was also issue in the bug tracker 
>>>https://bugs.launchpad.net/kicad/+bug/1817232
>>>And like guy from bug issue, I moved from Altium Designer and miss that 
>>>dialog as well. 
>>>Can you please look at that and commit if you think it's useful or tell me 
>>>what to change.
>>>That's my commit in the github:
>>>https://github.com/jasuramme/kicad-source-mirror/commit/6290375c1d41ddb89d4b08067593f170c7d344c5
>>>and branch:
>>>https://github.com/jasuramme/kicad-source-mirror/tree/statistic_dialog
>>>and there's also patch and dialogs pics in the attachment.
>>>
>>>___
>>>Mailing list:  https://launchpad.net/~kicad-developers
>>>Post to     :  kicad-developers@lists.launchpad.net
>>>Unsubscribe :  https://launchpad.net/~kicad-developers
>>>More help   :  https://help.launchpad.net/ListHelp
>>___
>>Mailing list:  https://launchpad.net/~kicad-developers
>>Post to :  kicad-developers@lists.launchpad.net
>>Unsubscribe :  https://launchpad.net/~kicad-developers
>>More help   :  https://help.launchpad.net/ListHelp
>


-- 
Alexander Shuklin
___
Mailing list: https://launchpad.net/~kicad-developers
Post