Re: [Kicad-developers] Version 5 upgrade document review.

[hauptmech]

Hi Wayne,

Really awesome that you are creating this documentation!

A couple thoughts:
* No one reads documentation unless they have to. Usually after stabbing 
in the dark for a while.

* If one has to read documentation, one wants it short and to the point.
* Whatever basic knowledge you want the reader to have about how kicad 
works, they won't have it.


With that in mind I did a little example editing with the following goals:

* Link to any info that is a requirement for understanding this 
document. If you can't find any existing documentation to link to, 
that's a good clue that we need to fill in more info locally.

* Leave out as many extra words as possible.

https://github.com/hauptmech/kicad-doc/blob/master/src/kicad/kicad_upgrading_from_v4_to_v5.adoc
https://github.com/hauptmech/kicad-doc/blob/master/src/eeschema/eeschema_symbol_library_table.adoc

It's not formatted as a patch because I only edited a few paragraphs, 
and in those I rewrote things completely as an example of the above.





On 23/06/18 04:10, Wayne Stambaugh wrote:

I pushed the v5 upgrade document to my personal repo[1] on git hub.  I
made it part of the KiCad documentation but I don't have a strong
opinion about where to add it.  This just seemed like the most logic
place.  Please review it when you get a chance.  If you find any issues
let me know, send me a patch, or submit a pull request against my doc
repo.  Keep in mind that this document is only to detail the changes
that will effect project compatibility with older versions of kicad and
the perils of symbol remapping.  Thanks in advance for the help.

Cheers,

Wayne

[1]:
https://github.com/stambaughw/kicad-doc/blob/master/src/kicad/kicad_upgrading_from_v4_to_v5.adoc

___
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] Version 5 upgrade document review.

[Marco Ciampa]

My 2 cents suggestions...

On Fri, Jun 22, 2018 at 11:29:11AM -0500, Adam Wolf wrote:
> I think this looks pretty good.

Agree.

[...]

> What about adding a sentence near the beginning that says something
> like "Ideally, upgrading to a new version of KiCad would take no
> effort on your part.  We take effort to minimize changes that require
> special handling, but sometimes they are required in order to fix
> serious issues."

Agree again.

> 
> For upgrading users:
> 
> I will recommend that they should make a backup of their projects per
> this document.

Even if the program warns and does a backup by itself, suggesting to do
one more backup copy is IMHO a good idea anyway.

TIA

-- 


Marco Ciampa

I know a joke about UDP, but you might not get it.



 GNU/Linux User #78271
 FSFE fellow #364




___
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] GAL: Draw hole even if pad has no layer

[Seth Hillbrand]

OK, thank you.  You are right.  I see the difference now.  I was deleting
the layer tag to test it.  The board has the layer tag but it is empty.  I
also confirm the error you mention.

But I'm still not sure about the patch's approach.  I think I am in
agreement with JP here that the correct way to deal with the malformed
board is to present the user with options to fix it when they open the
file.  We should probably treat the missing layer tag in the same fashion
then as well.

-S

Am Fr., 22. Juni 2018 um 12:54 Uhr schrieb Andrzej Wolski <
awolski.ki...@gmail.com>:

> No, this IS an error in the board :)
> If you open pad properties and click OK, it won't let you save it as is,
> you will have to enable copper layers.
> NPTH pads also HAVE TO exists on copper layers (I don't understand why,
> but they do).
>
> Also, as I already mentioned, current GAL behavior is different from 4.0
> GAL and legacy, so this is a regression.
>
> Andrzej
>
> W dniu 2018-06-22 o 21:44, Seth Hillbrand pisze:
>
> Ah.  This is not an error in the board.  This is just an NPTH.  If you
> click on it in GAL, you will see it.
>
> I think the correct patch to this should check the pad type instead of
> drawing one with no layers.
>
> -S
>
> Am Fr., 22. Juni 2018 um 12:33 Uhr schrieb Andrzej Wolski <
> awolski.ki...@gmail.com>:
>
>> IIRC you have to leave (layers) to reproduce this.
>>
>> This is a board where I found the issue:
>>
>> https://github.com/mntmn/reform/blob/master/electronics/reform-motherboard.kicad_pcb
>> There are two mPCIE connectors in the center, they have NPTH alignment
>> holes, you can see them in legacy mode.
>>
>> Andrzej
>>
>> W dniu 2018-06-22 o 20:06, Seth Hillbrand pisze:
>>
>> Andrzej-
>>
>> I just tested this, editing a file to remove the layers from a pad and
>> KiCad automatically adds the pad back to all copper layers.  I see the pad
>> in pcbnew and can edit it.
>>
>> Can you provide a board that demonstrates the issue?  Maybe it was only
>> the test board I used?
>>
>> -S
>>
>> Am Fr., 22. Juni 2018 um 10:51 Uhr schrieb Andrzej Wolski <
>> awolski.ki...@gmail.com>:
>>
>>> Hi Seth,
>>>
>>> current behavior is that malformed pad holes are always hidden, so you
>>> can't see on the screen something that exists on your PCB and will be
>>> plotted in drill files. This patch makes those holes visible.
>>>
>>> Andrzej
>>>
>>> W dniu 2018-06-22 o 17:46, Seth Hillbrand pisze:
>>>
>>> ​Andrzej-
>>>
>>> Can you explain the issue that this patch addresses?  I read the commit
>>> message but it looks like malformed pads (GetLayerSet().any() == 0) are no
>>> longer hidden.  This seems counter-intuitive but maybe I'm just not seeing
>>> the problem.
>>>
>>> Thanks!
>>> Seth​
>>>
>>>
>>>
>>> Am Fr., 22. Juni 2018 um 03:57 Uhr schrieb Andrzej Wolski <
>>> awolski.ki...@gmail.com>:
>>>

 ___
 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] [PATCH] GAL: Draw hole even if pad has no layer

[Seth Hillbrand]

Ah.  This is not an error in the board.  This is just an NPTH.  If you
click on it in GAL, you will see it.

I think the correct patch to this should check the pad type instead of
drawing one with no layers.

-S

Am Fr., 22. Juni 2018 um 12:33 Uhr schrieb Andrzej Wolski <
awolski.ki...@gmail.com>:

> IIRC you have to leave (layers) to reproduce this.
>
> This is a board where I found the issue:
>
> https://github.com/mntmn/reform/blob/master/electronics/reform-motherboard.kicad_pcb
> There are two mPCIE connectors in the center, they have NPTH alignment
> holes, you can see them in legacy mode.
>
> Andrzej
>
> W dniu 2018-06-22 o 20:06, Seth Hillbrand pisze:
>
> Andrzej-
>
> I just tested this, editing a file to remove the layers from a pad and
> KiCad automatically adds the pad back to all copper layers.  I see the pad
> in pcbnew and can edit it.
>
> Can you provide a board that demonstrates the issue?  Maybe it was only
> the test board I used?
>
> -S
>
> Am Fr., 22. Juni 2018 um 10:51 Uhr schrieb Andrzej Wolski <
> awolski.ki...@gmail.com>:
>
>> Hi Seth,
>>
>> current behavior is that malformed pad holes are always hidden, so you
>> can't see on the screen something that exists on your PCB and will be
>> plotted in drill files. This patch makes those holes visible.
>>
>> Andrzej
>>
>> W dniu 2018-06-22 o 17:46, Seth Hillbrand pisze:
>>
>> ​Andrzej-
>>
>> Can you explain the issue that this patch addresses?  I read the commit
>> message but it looks like malformed pads (GetLayerSet().any() == 0) are no
>> longer hidden.  This seems counter-intuitive but maybe I'm just not seeing
>> the problem.
>>
>> Thanks!
>> Seth​
>>
>>
>>
>> Am Fr., 22. Juni 2018 um 03:57 Uhr schrieb Andrzej Wolski <
>> awolski.ki...@gmail.com>:
>>
>>>
>>> ___
>>> 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] [PATCH] Save through hole pads color to config file

[Kevin Cozens]

On 2018-06-22 06:56 AM, Andrzej Wolski wrote:
From ebfb1d5cc9ebdeddaa518f14e7c86b7e5c1bbdaa Mon Sep 17 00:00:00 2001 
From: Andrzej Wolski  Date: Fri, 22 Jun 2018

01:35:05 +0200 Subject: [PATCH] Save through hole pads color to config
file


This seems like it changes the contents of an existing file. Is this a file
entry that is already documented? If not, someone needs to update the
documentation for the config file.

--
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] [PATCH] GAL: Draw hole even if pad has no layer

[Andrzej Wolski]

No, this IS an error in the board :)
If you open pad properties and click OK, it won't let you save it as is, 
you will have to enable copper layers.
NPTH pads also HAVE TO exists on copper layers (I don't understand why, 
but they do).


Also, as I already mentioned, current GAL behavior is different from 4.0 
GAL and legacy, so this is a regression.


Andrzej

W dniu 2018-06-22 o 21:44, Seth Hillbrand pisze:
Ah.  This is not an error in the board.  This is just an NPTH.  If you 
click on it in GAL, you will see it.


I think the correct patch to this should check the pad type instead of 
drawing one with no layers.


-S

Am Fr., 22. Juni 2018 um 12:33 Uhr schrieb Andrzej Wolski 
mailto:awolski.ki...@gmail.com>>:


IIRC you have to leave (layers) to reproduce this.

This is a board where I found the issue:

https://github.com/mntmn/reform/blob/master/electronics/reform-motherboard.kicad_pcb
There are two mPCIE connectors in the center, they have NPTH
alignment holes, you can see them in legacy mode.

Andrzej

W dniu 2018-06-22 o 20:06, Seth Hillbrand pisze:

Andrzej-

I just tested this, editing a file to remove the layers from a
pad and KiCad automatically adds the pad back to all copper
layers.  I see the pad in pcbnew and can edit it.

Can you provide a board that demonstrates the issue?  Maybe it
was only the test board I used?

-S

Am Fr., 22. Juni 2018 um 10:51 Uhr schrieb Andrzej Wolski
mailto:awolski.ki...@gmail.com>>:

Hi Seth,

current behavior is that malformed pad holes are always
hidden, so you can't see on the screen something that exists
on your PCB and will be plotted in drill files. This patch
makes those holes visible.

Andrzej

W dniu 2018-06-22 o 17:46, Seth Hillbrand pisze:

​Andrzej-

Can you explain the issue that this patch addresses?  I read
the commit message but it looks like malformed pads
(GetLayerSet().any() == 0) are no longer hidden.  This seems
counter-intuitive but maybe I'm just not seeing the problem.

Thanks!
Seth​



Am Fr., 22. Juni 2018 um 03:57 Uhr schrieb Andrzej Wolski
mailto:awolski.ki...@gmail.com>>:


___
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] [PATCH] GAL: Draw hole even if pad has no layer

[Andrzej Wolski]

IIRC you have to leave (layers) to reproduce this.

This is a board where I found the issue:
https://github.com/mntmn/reform/blob/master/electronics/reform-motherboard.kicad_pcb
There are two mPCIE connectors in the center, they have NPTH alignment 
holes, you can see them in legacy mode.


Andrzej

W dniu 2018-06-22 o 20:06, Seth Hillbrand pisze:

Andrzej-

I just tested this, editing a file to remove the layers from a pad and 
KiCad automatically adds the pad back to all copper layers.  I see the 
pad in pcbnew and can edit it.


Can you provide a board that demonstrates the issue?  Maybe it was 
only the test board I used?


-S

Am Fr., 22. Juni 2018 um 10:51 Uhr schrieb Andrzej Wolski 
mailto:awolski.ki...@gmail.com>>:


Hi Seth,

current behavior is that malformed pad holes are always hidden, so
you can't see on the screen something that exists on your PCB and
will be plotted in drill files. This patch makes those holes visible.

Andrzej

W dniu 2018-06-22 o 17:46, Seth Hillbrand pisze:

​Andrzej-

Can you explain the issue that this patch addresses?  I read the
commit message but it looks like malformed pads
(GetLayerSet().any() == 0) are no longer hidden.  This seems
counter-intuitive but maybe I'm just not seeing the problem.

Thanks!
Seth​



Am Fr., 22. Juni 2018 um 03:57 Uhr schrieb Andrzej Wolski
mailto:awolski.ki...@gmail.com>>:


___
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] [PATCH] GAL: Draw hole even if pad has no layer

[Andrzej Wolski]

Those pads are shown in 4.0 GAL and in 5.0 legacy, only 5.0 GAL has this 
problem, so to me this is a regression fix rather than workaround.


Fixing those pads may be a good idea, but that is another matter.

Andrzej


W dniu 2018-06-22 o 20:03, jp charras pisze:

Le 22/06/2018 à 19:51, Andrzej Wolski a écrit :

Hi Seth,

current behavior is that malformed pad holes are always hidden, so you can't 
see on the screen
something that exists on your PCB and will be plotted in drill files. This 
patch makes those holes
visible.

Andrzej

OK,

But perhaps a better way is to fix this kind of malformed pads, as perhaps they 
can create other
issues (especially related to DRC).

Showing them is a workaround, not a fix.



W dniu 2018-06-22 o 17:46, Seth Hillbrand pisze:

​Andrzej-

Can you explain the issue that this patch addresses?  I read the commit message 
but it looks like
malformed pads (GetLayerSet().any() == 0) are no longer hidden.  This seems 
counter-intuitive but
maybe I'm just not seeing the problem.

Thanks!
Seth​




___
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] Version 5 upgrade document review.

[Wayne Stambaugh]

Good catch.  I just pushed the fix to my repo.  Thanks.

Wayne

On 06/22/2018 02:33 PM, Steven A. Falco wrote:
> A small typo - the last note in the file has the phrase "by using opening".  
> That should either be "by using" or "by opening".
> 
>   Steve
> 
> On 06/22/2018 12:10 PM, Wayne Stambaugh wrote:
>> I pushed the v5 upgrade document to my personal repo[1] on git hub.  I
>> made it part of the KiCad documentation but I don't have a strong
>> opinion about where to add it.  This just seemed like the most logic
>> place.  Please review it when you get a chance.  If you find any issues
>> let me know, send me a patch, or submit a pull request against my doc
>> repo.  Keep in mind that this document is only to detail the changes
>> that will effect project compatibility with older versions of kicad and
>> the perils of symbol remapping.  Thanks in advance for the help.
>>
>> Cheers,
>>
>> Wayne
>>
>> [1]:
>> https://github.com/stambaughw/kicad-doc/blob/master/src/kicad/kicad_upgrading_from_v4_to_v5.adoc
>>
>> ___
>> 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] Bug Tracker Milestone

[Wayne Stambaugh]

I'm fine with this going into 5.1 as long as we are not changing the
board file format which doesn't appear to be the case with these changes.

On 06/22/2018 10:28 AM, Jeff Young wrote:
> The dialog work started life as eradicating the g_UserUnit global
> variable so that the different apps wouldn’t fight over it.  It
> therefore includes most of the dialogs in Kicad.
> 
> They are all “clean” with respect to 5.1 with one exception: the new
> Board Setup paged dialog.  
> 
> It includes:
> 
>   * items that were historically stored in the config when they should
> be in the board: diff pair widths and gaps, courtyard DRC flags
>   * items that weren’t stored at all: diff pair via gaps, default
> italic-text and unlocked-text (now called “Keep Upright”)
>   * new features: hole-to-hole min, default text/graphic properties for
> non-copper, non-silkscreen layers
> 
> 
> As of now they’re simply background-highlighted in yellow until we
> decide what to do with them:
> 
> 
> 
> 
> Options would include:
> 
> 1) leave this dialog out of 5.1
> 2) modify the dialog to not include the yellow stuff
> 3) put them all in config and add a temporary disclaimer to the dialog
> indicating they aren’t board-specific
> 
> Cheers,
> Jeff.
> 
> 
>> On 22 Jun 2018, at 08:37, Wayne Stambaugh > > wrote:
>>
>> Nick,
>>
>> Thanks for taking care of this.  It was on my list.  There is one
>> caveat.  We will need to be diligent about what changes we allow into
>> 5.0.1 versus 5.1.0.  Please keep in mind that micro releases are bug fix
>> only so no string or feature changes.  Minor feature and string changes
>> will have to be pushed into 5.1.  Feature changes in 5.1 one are
>> expected to be minor in impact such as Jeff's configuration dialog work
>> or minor improvements to the field editor dialog.  Major features such
>> as the new file formats and converting eeschema over to gal are for v6.
>> This will force us to be diligent about keeping merges sets isolated so
>> they can be cherry picked into the appropriate v5 release.  Please do
>> not make changes that are slated for v5 with changes that are part of v6
>> or we will have an awful time back porting.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 06/22/2018 03:52 AM, Nick Østergaard wrote:
>>> Hello Seth
>>>
>>> I have created the following milestone names:
>>>
>>> 5.1.0
>>> This is for fixes that are backportable from master, it could be string
>>> fixes and minor features.
>>>
>>>
>>> 5.0.1
>>> Post release fixes that does not involve string changes.
>>>
>>>
>>> Att. Wayne, I would like you to say this is ok, or if we should use some
>>> other names.
>>>
>>> Nick
>>>
>>> 2018-06-21 18:10 GMT+02:00 Seth Hillbrand >> 
>>> >:
>>>
>>>    ​Hi Devs-
>>>
>>>    Can we get a v5.1 milestone on the bug tracker?  I'd like to start
>>>    separating the items we are planning for the point release from the
>>>    the v6 release.  That way we can begin to discuss which belong where.
>>>
>>>    It would probably be useful to also have a 5.0.1 milestone that we
>>>    can assign post-release bugs to that don't involve string changes.
>>>
>>>    ​Thanks-
>>>    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
>>>
>>
>> ___
>> 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] Version 5 upgrade document review.

[Steven A. Falco]

A small typo - the last note in the file has the phrase "by using opening".  
That should either be "by using" or "by opening".

Steve

On 06/22/2018 12:10 PM, Wayne Stambaugh wrote:
> I pushed the v5 upgrade document to my personal repo[1] on git hub.  I
> made it part of the KiCad documentation but I don't have a strong
> opinion about where to add it.  This just seemed like the most logic
> place.  Please review it when you get a chance.  If you find any issues
> let me know, send me a patch, or submit a pull request against my doc
> repo.  Keep in mind that this document is only to detail the changes
> that will effect project compatibility with older versions of kicad and
> the perils of symbol remapping.  Thanks in advance for the help.
> 
> Cheers,
> 
> Wayne
> 
> [1]:
> https://github.com/stambaughw/kicad-doc/blob/master/src/kicad/kicad_upgrading_from_v4_to_v5.adoc
> 
> ___
> 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] [PATCH] Save through hole pads color to config file

[Wayne Stambaugh]

Hi Andrzej,

Good catch.  I merged your patch.  Thank you for your contribution to KiCad.

Cheers,

Wayne

On 06/22/2018 06:56 AM, Andrzej Wolski wrote:
> 
> 
> 
> ___
> 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] Version 5 upgrade document review.

[Adam Wolf]

We can install different versions of the KiCad apps on macOS, but it
is not easy to have different versions of the "support directory" at
the same time.

Adam
On Fri, Jun 22, 2018 at 1:21 PM Wayne Stambaugh  wrote:
>
> On 06/22/2018 12:29 PM, Adam Wolf wrote:
> > I think this looks pretty good.
> >
> > Is there somewhere we suggest people should go to ask for help?
>
> The KiCad user forum is the best place to go for help.
>
> >
> > What about adding a sentence near the beginning that says something
> > like "Ideally, upgrading to a new version of KiCad would take no
> > effort on your part.  We take effort to minimize changes that require
> > special handling, but sometimes they are required in order to fix
> > serious issues."
> >
> > For upgrading users:
> >
> > I will recommend that they should make a backup of their projects per
> > this document.
>
> There is a warning in the doc about backing up even though backups are
> made by the remapping code.
>
> >
> > Should I recommend for them to make a backup of their KiCad support
> > directory (the one with template, library, et al)?
>
> If you cannot install multiple version of KiCad on macos, than the user
> would have to keep the v4 symbol libraries unless they didn't use them
> in any of their schematics or they should use step 5 in the document.
>
> >
> > Regarding fp-table-lib, should I recommend that users should make a
> > backup of their current one?  Can I just tell them to move it to a
> > backup, and will KiCad use a good one if there isn't a user-specific
> > one?  Do I need to tell them to go into template/ and copy that one?
>
> Not unless they want to copy the new default file and have customized
> their global fp-lib-table.
>
> >
> > Do I need to specify that users copy sym-table-lib out, or will KiCad
> > do that automatically if they don't have one?
>
> Eeschema will prompt the user the first time it's run and there is no
> sym-lib-table file.  The default table contains all of the new symbol
> libraries that are in the repo.
>
> >
> > (I feel pretty guilty asking these questions but I think the
> > alternative is that I dig into it and hold up the release :( )
>
> No problem.  All of this is addressed in the doc so pointing this doc
> would be an easy out.  It would also eliminate the need to keep things
> synced should they change.
>
> >
> > Adam
> > On Fri, Jun 22, 2018 at 11:10 AM Wayne Stambaugh  
> > wrote:
> >>
> >> I pushed the v5 upgrade document to my personal repo[1] on git hub.  I
> >> made it part of the KiCad documentation but I don't have a strong
> >> opinion about where to add it.  This just seemed like the most logic
> >> place.  Please review it when you get a chance.  If you find any issues
> >> let me know, send me a patch, or submit a pull request against my doc
> >> repo.  Keep in mind that this document is only to detail the changes
> >> that will effect project compatibility with older versions of kicad and
> >> the perils of symbol remapping.  Thanks in advance for the help.
> >>
> >> Cheers,
> >>
> >> Wayne
> >>
> >> [1]:
> >> https://github.com/stambaughw/kicad-doc/blob/master/src/kicad/kicad_upgrading_from_v4_to_v5.adoc
> >>
> >> ___
> >> 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] Version 5 upgrade document review.

[Wayne Stambaugh]

On 06/22/2018 12:29 PM, Adam Wolf wrote:
> I think this looks pretty good.
> 
> Is there somewhere we suggest people should go to ask for help?

The KiCad user forum is the best place to go for help.

> 
> What about adding a sentence near the beginning that says something
> like "Ideally, upgrading to a new version of KiCad would take no
> effort on your part.  We take effort to minimize changes that require
> special handling, but sometimes they are required in order to fix
> serious issues."
> 
> For upgrading users:
> 
> I will recommend that they should make a backup of their projects per
> this document.

There is a warning in the doc about backing up even though backups are
made by the remapping code.

> 
> Should I recommend for them to make a backup of their KiCad support
> directory (the one with template, library, et al)?

If you cannot install multiple version of KiCad on macos, than the user
would have to keep the v4 symbol libraries unless they didn't use them
in any of their schematics or they should use step 5 in the document.

> 
> Regarding fp-table-lib, should I recommend that users should make a
> backup of their current one?  Can I just tell them to move it to a
> backup, and will KiCad use a good one if there isn't a user-specific
> one?  Do I need to tell them to go into template/ and copy that one?

Not unless they want to copy the new default file and have customized
their global fp-lib-table.

> 
> Do I need to specify that users copy sym-table-lib out, or will KiCad
> do that automatically if they don't have one?

Eeschema will prompt the user the first time it's run and there is no
sym-lib-table file.  The default table contains all of the new symbol
libraries that are in the repo.

> 
> (I feel pretty guilty asking these questions but I think the
> alternative is that I dig into it and hold up the release :( )

No problem.  All of this is addressed in the doc so pointing this doc
would be an easy out.  It would also eliminate the need to keep things
synced should they change.

> 
> Adam
> On Fri, Jun 22, 2018 at 11:10 AM Wayne Stambaugh  wrote:
>>
>> I pushed the v5 upgrade document to my personal repo[1] on git hub.  I
>> made it part of the KiCad documentation but I don't have a strong
>> opinion about where to add it.  This just seemed like the most logic
>> place.  Please review it when you get a chance.  If you find any issues
>> let me know, send me a patch, or submit a pull request against my doc
>> repo.  Keep in mind that this document is only to detail the changes
>> that will effect project compatibility with older versions of kicad and
>> the perils of symbol remapping.  Thanks in advance for the help.
>>
>> Cheers,
>>
>> Wayne
>>
>> [1]:
>> https://github.com/stambaughw/kicad-doc/blob/master/src/kicad/kicad_upgrading_from_v4_to_v5.adoc
>>
>> ___
>> 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] [PATCH] GAL: Draw hole even if pad has no layer

[Seth Hillbrand]

Andrzej-

I just tested this, editing a file to remove the layers from a pad and
KiCad automatically adds the pad back to all copper layers.  I see the pad
in pcbnew and can edit it.

Can you provide a board that demonstrates the issue?  Maybe it was only the
test board I used?

-S

Am Fr., 22. Juni 2018 um 10:51 Uhr schrieb Andrzej Wolski <
awolski.ki...@gmail.com>:

> Hi Seth,
>
> current behavior is that malformed pad holes are always hidden, so you
> can't see on the screen something that exists on your PCB and will be
> plotted in drill files. This patch makes those holes visible.
>
> Andrzej
>
> W dniu 2018-06-22 o 17:46, Seth Hillbrand pisze:
>
> ​Andrzej-
>
> Can you explain the issue that this patch addresses?  I read the commit
> message but it looks like malformed pads (GetLayerSet().any() == 0) are no
> longer hidden.  This seems counter-intuitive but maybe I'm just not seeing
> the problem.
>
> Thanks!
> Seth​
>
>
>
> Am Fr., 22. Juni 2018 um 03:57 Uhr schrieb Andrzej Wolski <
> awolski.ki...@gmail.com>:
>
>>
>> ___
>> 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] [PATCH] GAL: Draw hole even if pad has no layer

[jp charras]

Le 22/06/2018 à 19:51, Andrzej Wolski a écrit :
> Hi Seth,
> 
> current behavior is that malformed pad holes are always hidden, so you can't 
> see on the screen
> something that exists on your PCB and will be plotted in drill files. This 
> patch makes those holes
> visible.
> 
> Andrzej

OK,

But perhaps a better way is to fix this kind of malformed pads, as perhaps they 
can create other
issues (especially related to DRC).

Showing them is a workaround, not a fix.


> 
> W dniu 2018-06-22 o 17:46, Seth Hillbrand pisze:
>> ​Andrzej-
>>
>> Can you explain the issue that this patch addresses?  I read the commit 
>> message but it looks like
>> malformed pads (GetLayerSet().any() == 0) are no longer hidden.  This seems 
>> counter-intuitive but
>> maybe I'm just not seeing the problem.
>>
>> Thanks!
>> Seth​

-- 
Jean-Pierre CHARRAS

___
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] GAL: Draw hole even if pad has no layer

[Andrzej Wolski]

Hi Seth,

current behavior is that malformed pad holes are always hidden, so you 
can't see on the screen something that exists on your PCB and will be 
plotted in drill files. This patch makes those holes visible.


Andrzej

W dniu 2018-06-22 o 17:46, Seth Hillbrand pisze:

​Andrzej-

Can you explain the issue that this patch addresses?  I read the 
commit message but it looks like malformed pads (GetLayerSet().any() 
== 0) are no longer hidden.  This seems counter-intuitive but maybe 
I'm just not seeing the problem.


Thanks!
Seth​



Am Fr., 22. Juni 2018 um 03:57 Uhr schrieb Andrzej Wolski 
mailto:awolski.ki...@gmail.com>>:



___
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] Version 5 upgrade document review.

[Adam Wolf]

I think this looks pretty good.

Is there somewhere we suggest people should go to ask for help?

What about adding a sentence near the beginning that says something
like "Ideally, upgrading to a new version of KiCad would take no
effort on your part.  We take effort to minimize changes that require
special handling, but sometimes they are required in order to fix
serious issues."

For upgrading users:

I will recommend that they should make a backup of their projects per
this document.

Should I recommend for them to make a backup of their KiCad support
directory (the one with template, library, et al)?

Regarding fp-table-lib, should I recommend that users should make a
backup of their current one?  Can I just tell them to move it to a
backup, and will KiCad use a good one if there isn't a user-specific
one?  Do I need to tell them to go into template/ and copy that one?

Do I need to specify that users copy sym-table-lib out, or will KiCad
do that automatically if they don't have one?

(I feel pretty guilty asking these questions but I think the
alternative is that I dig into it and hold up the release :( )

Adam
On Fri, Jun 22, 2018 at 11:10 AM Wayne Stambaugh  wrote:
>
> I pushed the v5 upgrade document to my personal repo[1] on git hub.  I
> made it part of the KiCad documentation but I don't have a strong
> opinion about where to add it.  This just seemed like the most logic
> place.  Please review it when you get a chance.  If you find any issues
> let me know, send me a patch, or submit a pull request against my doc
> repo.  Keep in mind that this document is only to detail the changes
> that will effect project compatibility with older versions of kicad and
> the perils of symbol remapping.  Thanks in advance for the help.
>
> Cheers,
>
> Wayne
>
> [1]:
> https://github.com/stambaughw/kicad-doc/blob/master/src/kicad/kicad_upgrading_from_v4_to_v5.adoc
>
> ___
> 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] Version 5 upgrade document review.

[Wayne Stambaugh]

I pushed the v5 upgrade document to my personal repo[1] on git hub.  I
made it part of the KiCad documentation but I don't have a strong
opinion about where to add it.  This just seemed like the most logic
place.  Please review it when you get a chance.  If you find any issues
let me know, send me a patch, or submit a pull request against my doc
repo.  Keep in mind that this document is only to detail the changes
that will effect project compatibility with older versions of kicad and
the perils of symbol remapping.  Thanks in advance for the help.

Cheers,

Wayne

[1]:
https://github.com/stambaughw/kicad-doc/blob/master/src/kicad/kicad_upgrading_from_v4_to_v5.adoc

___
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] GAL: Draw hole even if pad has no layer

[Seth Hillbrand]

​Andrzej-

Can you explain the issue that this patch addresses?  I read the commit
message but it looks like malformed pads (GetLayerSet().any() == 0) are no
longer hidden.  This seems counter-intuitive but maybe I'm just not seeing
the problem.

Thanks!
Seth​



Am Fr., 22. Juni 2018 um 03:57 Uhr schrieb Andrzej Wolski <
awolski.ki...@gmail.com>:

>
> ___
> 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] [PATCH] Fix overbar drawing for non-italic text

[Andrzej Wolski]

No, the patch didn't go the wrong way.
If you try to shorten the right side of the bar, for some characters it 
will look really bad, and in case of "I" it will turn into dot.

This is before patch:
https://imgur.com/a/TjibR0Q

Andrzej


W dniu 2018-06-22 o 15:40, Kevin Cozens pisze:

On 2018-06-22 07:01 AM, Andrzej Wolski wrote:

This is an illustration of what this patch do:
https://imgur.com/a/GxIeLkA


Hm... did the patch go the wrong way with the change to the position 
and length of the bar over non-italicized text? Before the bar started 
at the left side of the letter and extends past the right side of the 
letter. After it starts before the letter and extends past the right 
side. Contrast that to italicized text where the bar starts and ends 
based on the left-most and right-most part of the drawn letter.


I think a patch should shorten the right-hand extent of the bar over 
non-italicized text so it is only over the letter.





___
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] explode an intersection, how to start?

[Ouabache Designworks]

On Thu, Jun 21, 2018 at 9:22 PM, jc  wrote:

> I would like to explode an intersect, like 2 lines,if crossed, turn into 4.
>
>
> This can be done easily with a line of command in autocad, 30yrs ago.
>
> I want to mske that happen in 4.0.7. Where should i start?
>
>

Start by asking if you really want to do that. Two lines crossing @ 90
degrees is a
no brainer but what about 45 degress? Does the junction have to align to
the snap grid?
Can you disconnect them by deleting the junction. This can be a can of
worms.

Some tools do not allow 4 corner junctions because in the old days of blue
line machines
you could have copies of copies of copies and two crossing lines would blur
and start to
look like a junction. If you see 3 lines then you know there is a
connection but 4 lines
is never a connection.

John Eaton
___
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 to help users handle updating from version 4 to version 5 with regards to fp-lib-table handling?

[Wayne Stambaugh]

On 06/22/2018 09:19 AM, Carsten Schoenert wrote:
> Am 22.06.2018 um 14:28 schrieb Wayne Stambaugh:
>> This is not a trivial fix.  Blindly copying the default global library
>> tables every time they change would overwrite any user customization
>> which is a not an option.  It then becomes a merge operation which is
>> far more complex.  I'm not opposed to an optional merge solution if
>> someone has the time to implement it.
> 
> Yes, doing it that way is a real complex thing that will be PITA.
> 
> But why KiCad needs that file if it also could use the default
> configuration from the package and only place differential and
> additional data from the user context in that file and load the config
> from here on top of the default config?

This is a potential solution.  There is no limit to how many library
tables that can be chained.  I see several issues with this solution.

Users who track the development libraries will have most likely fully
duplicate tables in there user config which could slow down the
footprint lookup and browsing although it would be minimal.

Given our history of not getting the default install path correct,
finding the default library tables could be problematic.

Changing a symbol library table could lead to missing and/or broken
symbols which causes it's own set of issues.

Changing a footprint library table could result in unexpected footprints
being pulled into a board.

> 
> It looks a bit wrong for me to save the default data within the user
> context which will bring such difficult circumstances then.
> 

___
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] Fix overbar drawing for non-italic text

[Kevin Cozens]

On 2018-06-22 07:01 AM, Andrzej Wolski wrote:

This is an illustration of what this patch do:
https://imgur.com/a/GxIeLkA


Hm... did the patch go the wrong way with the change to the position and 
length of the bar over non-italicized text? Before the bar started at the 
left side of the letter and extends past the right side of the letter. After 
it starts before the letter and extends past the right side. Contrast that 
to italicized text where the bar starts and ends based on the left-most and 
right-most part of the drawn letter.


I think a patch should shorten the right-hand extent of the bar over 
non-italicized text so it is only over the letter.


--
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] How to help users handle updating from version 4 to version 5 with regards to fp-lib-table handling?

[Carsten Schoenert]

Am 22.06.2018 um 14:28 schrieb Wayne Stambaugh:
> This is not a trivial fix.  Blindly copying the default global library
> tables every time they change would overwrite any user customization
> which is a not an option.  It then becomes a merge operation which is
> far more complex.  I'm not opposed to an optional merge solution if
> someone has the time to implement it.

Yes, doing it that way is a real complex thing that will be PITA.

But why KiCad needs that file if it also could use the default
configuration from the package and only place differential and
additional data from the user context in that file and load the config
from here on top of the default config?

It looks a bit wrong for me to save the default data within the user
context which will bring such difficult circumstances then.

-- 
Regards
Carsten Schoenert

___
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 to help users handle updating from version 4 to version 5 with regards to fp-lib-table handling?

[Adam Wolf]

Wayne, I can pull the text into the DMG or else link to it--Seth's
idea of putting some text in the background to tell users who are
upgrading to actually read the README will remove any guilt I have
about excited users just assuming they know what to do and skipping
any docs.

Rather than a "we try to fix it" solution, is there any way for us to
just nag people based on a simple heuristic?  I have been heads-down
in esoteric macOS loader/linker/Python land for too long to know what
is going on with the majority of KiCad v5 :) but can we do something
like compare the sym lib and the fp lib and see if we think the sym
lib is v6 and the fp lib looks v5, we aim them at some online docs in
a nag window, along with a checkbox for "I know what I'm doing, please
don't ask me this again" that we save in preferences?  Please feel
free to literally ignore me if this is completely wrong.

Adam Wolf
On Fri, Jun 22, 2018 at 7:28 AM Wayne Stambaugh  wrote:
>
> On 06/22/2018 01:05 AM, Carsten Schoenert wrote:
> > Hi,
> >
> > Am 22.06.2018 um 04:52 schrieb Adam Wolf:
> > ...
> >> Is there any way we can detect if the fp-lib-table is out of sync and
> >> tell a user at run time?
> >
> > I'm too seeing this point not only related to the update now from V4 to
> > V5 and this is completely unrelated to the OS the user is running on at all.
> >
> > For my rather small local environment it was quite fast to remove the
> > old file and let KiCad put the new default file in place. But in more
> > complex installations this doing is very annoying and error prune
> > because users need to deal with manual reading of content. KiCad needs
> > some better (automatic) handling here. But not only telling the user
> > some required update, also doing this in a automatic way.
> >
>
> This is not a trivial fix.  Blindly copying the default global library
> tables every time they change would overwrite any user customization
> which is a not an option.  It then becomes a merge operation which is
> far more complex.  I'm not opposed to an optional merge solution if
> someone has the time to implement it.
>
> ___
> 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] Bug Tracker Milestone

[Wayne Stambaugh]

Nick,

Thanks for taking care of this.  It was on my list.  There is one
caveat.  We will need to be diligent about what changes we allow into
5.0.1 versus 5.1.0.  Please keep in mind that micro releases are bug fix
only so no string or feature changes.  Minor feature and string changes
will have to be pushed into 5.1.  Feature changes in 5.1 one are
expected to be minor in impact such as Jeff's configuration dialog work
or minor improvements to the field editor dialog.  Major features such
as the new file formats and converting eeschema over to gal are for v6.
This will force us to be diligent about keeping merges sets isolated so
they can be cherry picked into the appropriate v5 release.  Please do
not make changes that are slated for v5 with changes that are part of v6
or we will have an awful time back porting.

Cheers,

Wayne

On 06/22/2018 03:52 AM, Nick Østergaard wrote:
> Hello Seth
> 
> I have created the following milestone names:
> 
> 5.1.0
> This is for fixes that are backportable from master, it could be string
> fixes and minor features.
> 
> 
> 5.0.1
> Post release fixes that does not involve string changes.
> 
> 
> Att. Wayne, I would like you to say this is ok, or if we should use some
> other names.
> 
> Nick
> 
> 2018-06-21 18:10 GMT+02:00 Seth Hillbrand  >:
> 
> ​Hi Devs-
> 
> Can we get a v5.1 milestone on the bug tracker?  I'd like to start
> separating the items we are planning for the point release from the
> the v6 release.  That way we can begin to discuss which belong where.
> 
> It would probably be useful to also have a 5.0.1 milestone that we
> can assign post-release bugs to that don't involve string changes.
> 
> ​Thanks-
> 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
> 

___
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 to help users handle updating from version 4 to version 5 with regards to fp-lib-table handling?

[Wayne Stambaugh]

On 06/22/2018 01:05 AM, Carsten Schoenert wrote:
> Hi,
> 
> Am 22.06.2018 um 04:52 schrieb Adam Wolf:
> ...
>> Is there any way we can detect if the fp-lib-table is out of sync and
>> tell a user at run time?
> 
> I'm too seeing this point not only related to the update now from V4 to
> V5 and this is completely unrelated to the OS the user is running on at all.
> 
> For my rather small local environment it was quite fast to remove the
> old file and let KiCad put the new default file in place. But in more
> complex installations this doing is very annoying and error prune
> because users need to deal with manual reading of content. KiCad needs
> some better (automatic) handling here. But not only telling the user
> some required update, also doing this in a automatic way.
> 

This is not a trivial fix.  Blindly copying the default global library
tables every time they change would overwrite any user customization
which is a not an option.  It then becomes a merge operation which is
far more complex.  I'm not opposed to an optional merge solution if
someone has the time to implement it.

___
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 to help users handle updating from version 4 to version 5 with regards to fp-lib-table handling?

[Wayne Stambaugh]

I plan on pushing the preliminary v4 to v5 guide to my personal repo
today for review.  Hopefully, I can get enough comments and feedback by
the end of the weekend to finalize and merge it into the master kicad
documentation repo by Monday at the latest.  How hard would it be to
provide a link to this document in the dmg?  I don't know squat about
macos packaging so I'm not going to be much help other than providing
the documentation and the link to it.

Cheers,

Wayne

On 06/21/2018 11:59 PM, Adam Wolf wrote:
> I suppose the actual text of what to do maybe something in the V4->V5
> page that's being drafted.  If not, we should draft something up on
> the list here.
> 
> Adam
> On Thu, Jun 21, 2018 at 10:48 PM Adam Wolf
>  wrote:
>>
>> Sure.  I can even have just a message saying "If you are upgrading
>> KiCad, please read the README" with a little arrow to the README file.
>>
>> Next--what do I instruct our users to do?
>>
>> Adam
>> On Thu, Jun 21, 2018 at 10:45 PM Seth Hillbrand
>>  wrote:
>>>
>>> Adam, I've often seen applications use the background image of the DMG to 
>>> convey important information that they want the user to see during 
>>> installation.
>>>
>>> -S
>>>
>>>
>>> Am Do., 21. Juni 2018 um 19:52 Uhr schrieb Adam Wolf 
>>> :

 I am pretty concerned about this.  There is no place in the macOS
 package to put instructions that users will read.  (There is a README
 but I do not believe many people open it.)

 Is there any way we can detect if the fp-lib-table is out of sync and
 tell a user at run time?

 Adam
 On Wed, Jun 20, 2018 at 2:54 PM Rene Pöschl  wrote:
>
> Hello,
>
>
> I know we are in feature freeze. It seems a lot of people struggle with
> the transition from kicad 4 to kicad 5. One of the things that could
> help a lot would be some way of forcing a reset of the user config
> directory contents to the default. (cold also help later on if for some
> reason the config directory got compromised.)
>
> Especially for the fp-lib-table. It is really not obvious to a lot of
> people using the official library that this one would need to be reset
> after updating from kicad 4 to kicad 5. (The files for the official
> symbol and 3d libraries are updated. The sym-lib-table is "updated" as
> it never existed before. Meaning without user intervention the footprint
> library will be out of sync with all other types of libraries.)
>
> I think a message in the installer should be the least that should be
> done. (But that one will only work where kicad has a specific
> installation tool.)
>
> A message on first run of kicad 5 might be even better (maybe the
> message stating that the default sym-lib-table has been introduced could
> hint at the fact that the fp-lib-table might need resetting as well. Or
> a message with a tick-mark "do not show again".)
>
>
> ___
> 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] Slash character in fp-lib-table nick names?

[Wayne Stambaugh]

Thank you for testing it.  I appreciate the help.

On 06/21/2018 09:07 PM, Kaspar Emanuel wrote:
> Works great for me on latest nightly. Thanks again.
> 
> On 20 June 2018 at 18:52, Wayne Stambaugh  > wrote:
> 
> Kasper,
> 
> I just pushed the fix for this.  Please test it and let me know if you
> find any issues.  Keep in mind that this only effects the library
> nicknames.  The '/' character will still be illegal for symbol and
> footprint names.
> 
> Thanks,
> 
> Wayne
> 
> On 6/19/2018 4:04 PM, Kaspar Emanuel wrote:
> > Thanks Wayne, this will save me (and anyone else using
> > monostable/kicad_footprints
> >  >) quite a bit of
> > time!
> > 
> > ​
> > 
> > On 19 June 2018 at 19:13, Wayne Stambaugh  
> > >> wrote:
> > 
> >     I took a second look at this and you are correct.  The library table
> >     nickname character filter was changed to include the library item
> >     (symbol or footprint) name characters which is incorrect.  The valid
> >     library nickname characters are different from the valid library 
> item
> >     name characters.  I will fix this as soon as I get a chance.
> > 
> >     On 6/13/2018 4:59 PM, Kaspar Emanuel wrote:
> >     > Those are good reasons for not allowing slashes in the footprint 
> names
> >     > but I don’t see any reason for not allowing them in /library/ nick
> >     > names. As far as I can tell any character except |:| could be 
> allowed
> >     > before the |:|. It’s a pretty long standing “bug” so we could 
> view it as
> >     > standard. It will break "compatibility" with fp-lib-tables that 
> use the
> >     > slash character and users were never warned about using it.
> >     > 
> >     > If it /will/ be allowed in v6 why make people change it when going
> >     from
> >     > v4 to v5?
> >     > 
> >     > ​
> >     > 
> >     > On 13 June 2018 at 18:35, Wayne Stambaugh  
> >
> >     > 
>  >     > 
> >     >     AFAIK you cannot use slashes ('/') or colons (':') in either 
> a library
> >     >     (footprint or symbol) table nickname or a footprint or symbol 
> name.  If
> >     >     you could use a slash in a footprint library nickname in the 
> past, this
> >     >     was a bug and the fact that it worked was a fluke.  The 
> reason is that
> >     >     the library ID format is NICKNAME:FP_OR_SYM_NAME/REV.  The 
> other issue
> >     >     is that footprint names are actually the filename sans 
> extension.  Using
> >     >     a slash in a footprint name would render it unusable.  I am 
> going to fix
> >     >     this as part of the new schematic and symbol library file 
> format v6
> >     >     work.  The reason this was not done for v5 the fix will 
> require
> >     >     schematic, board, and footprint file format changes which I 
> didn't not
> >     >     want to do for v5 as we were already late into the 
> development cycle.
> >     > 
> >     >     On 6/13/2018 2:19 PM, Kaspar Emanuel wrote:
> >     >     > Sorry to bring this up again but it just strikes me as a 
> bit odd. Can we
> >     >     > not allow slash characters in the fp-lib-table as before 
> and not break
> >     >     > backwards compatibility? It seems to read fp-lib-tables 
> with slashes
> >     >     > fine but current KiCad nightly won't let me edit it. I am 
> up for making
> >     >     > a patch if there's a chance it could make it into v5.
> >     >     > 
> >     >     > 
> >     >     > On 10 May 2018 at 12:07, Wayne Stambaugh 
> mailto:stambau...@gmail.com>
> >
> >     
> >>
> >     >     >    >
> >     
>  wrote:
> >     >     >
> >     >     >     On 5/8/2018 6:27 PM, Kaspar Emanuel wrote:
> >     >     >     > I see, thanks for the info Wayne. So enforcing this
> >     for names in
> >     >     >     > _footprint_ lib-tables is simply done for code
> sharing?
> >     >     >     >
> >     >   

Re: [Kicad-developers] explode an intersection, how to start?

[Greg Smith]

Have a look at Python or KiCommand plugin. Also, consider asking this question 
on KiCad user forums.

Greg S.

> On Jun 21, 2018, at 11:22 PM, jc  wrote:
> 
> I would like to explode an intersect, like 2 lines,if crossed, turn into 4.
> 
> 
> This can be done easily with a line of command in autocad, 30yrs ago.
> 
> I want to mske that happen in 4.0.7. Where should i start?
> 
> 
> 
> ___
> 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] [PATCH] GAL: Draw hole even if pad has no layer

[Andrzej Wolski]

From d82e05f3328c95cb4443af7a2c0040ff1766fc96 Mon Sep 17 00:00:00 2001
From: Andrzej Wolski 
Date: Fri, 22 Jun 2018 12:07:56 +0200
Subject: [PATCH] GAL: Draw hole even if pad has no layer

While pcbnew does not allow to create THT pad without a copper layer,
there are boards that somehow have such pads. In that case, pad holes
(both PTH and NPTH) were not drawn in GAL.
---
 pcbnew/class_pad.cpp | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/pcbnew/class_pad.cpp b/pcbnew/class_pad.cpp
index c4a48c8e8..5bc6acc80 100644
--- a/pcbnew/class_pad.cpp
+++ b/pcbnew/class_pad.cpp
@@ -1316,7 +1316,8 @@ unsigned int D_PAD::ViewGetLOD( int aLayer, KIGFX::VIEW* 
aView ) const
 return HIDE;
 
 // Only draw the pad if at least one of the layers it crosses is being 
displayed
-if( board && !( board->GetVisibleLayers() & GetLayerSet() ).any() )
+// (or if pad has no layer)
+if( board && !( board->GetVisibleLayers() & GetLayerSet() ).any() && 
GetLayerSet().any() )
 return HIDE;
 
 // Netnames will be shown only if zoom is appropriate
-- 
2.16.2

___
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] Fix overbar drawing for non-italic text

[Andrzej Wolski]

This is an illustration of what this patch do:
https://imgur.com/a/GxIeLkA

Andrzej

___
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] [PATCH] Save through hole pads color to config file

[Andrzej Wolski]

From ebfb1d5cc9ebdeddaa518f14e7c86b7e5c1bbdaa Mon Sep 17 00:00:00 2001
From: Andrzej Wolski 
Date: Fri, 22 Jun 2018 01:35:05 +0200
Subject: [PATCH] Save through hole pads color to config file

TH Pads color is now user settable, so should be saved in config file.
---
 common/colors_design_settings.cpp | 1 +
 1 file changed, 1 insertion(+)

diff --git a/common/colors_design_settings.cpp 
b/common/colors_design_settings.cpp
index 6a2ba5a1a..4a34f7737 100644
--- a/common/colors_design_settings.cpp
+++ b/common/colors_design_settings.cpp
@@ -217,6 +217,7 @@ void COLORS_DESIGN_SETTINGS::setupConfigParams()
 Add( "Color4DPadBackEx", ITEM_COLOR( LAYER_PAD_BK ), GREEN );
 Add( "Color4DAnchorEx", ITEM_COLOR( LAYER_ANCHOR ), BLUE );
 Add( "Color4DPadFrontEx", ITEM_COLOR( LAYER_PAD_FR ), RED );
+Add( "Color4DPadThruHoleEx", ITEM_COLOR( LAYER_PADS_TH ), YELLOW );
 Add( "Color4DNonPlatedEx", ITEM_COLOR( LAYER_NON_PLATEDHOLES ), YELLOW );
 Add( "Color4DPCBBackground", ITEM_COLOR( LAYER_PCB_BACKGROUND ), BLACK );
 Add( "Color4DPCBCursor", ITEM_COLOR( LAYER_CURSOR ), WHITE );
-- 
2.16.2

___
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] [PATCH] Fix overbar drawing for non-italic text

[Andrzej Wolski]

From db2243f6fff9f1666049b501f45f582c2837caf2 Mon Sep 17 00:00:00 2001
From: Andrzej Wolski 
Date: Fri, 22 Jun 2018 12:51:53 +0200
Subject: [PATCH] Fix overbar drawing for non-italic text

Overbar was always indented inward, regardless if text was italic or not.
---
 common/gal/stroke_font.cpp | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/common/gal/stroke_font.cpp b/common/gal/stroke_font.cpp
index a6958f39c..10cc9e2c1 100644
--- a/common/gal/stroke_font.cpp
+++ b/common/gal/stroke_font.cpp
@@ -326,7 +326,9 @@ void STROKE_FONT::drawSingleLineText( const UTF8& aText )
 
 if( !last_had_overbar )
 {
-overbar_start_x += overbar_italic_comp;
+if( m_gal->IsFontItalic() )
+overbar_start_x += overbar_italic_comp;
+
 last_had_overbar = true;
 }
 
-- 
2.16.2

___
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] Bug Tracker Milestone

[Nick Østergaard]

Hello Seth

I have created the following milestone names:

5.1.0
This is for fixes that are backportable from master, it could be string
fixes and minor features.


5.0.1
Post release fixes that does not involve string changes.


Att. Wayne, I would like you to say this is ok, or if we should use some
other names.

Nick

2018-06-21 18:10 GMT+02:00 Seth Hillbrand :

> ​Hi Devs-
>
> Can we get a v5.1 milestone on the bug tracker?  I'd like to start
> separating the items we are planning for the point release from the the v6
> release.  That way we can begin to discuss which belong where.
>
> It would probably be useful to also have a 5.0.1 milestone that we can
> assign post-release bugs to that don't involve string changes.
>
> ​Thanks-
> 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