Re: [Kicad-developers] Resistor 2512 footprint [Kicad 4.07]

[hauptmech]

You should be able to check the footprint just by looking at it in a 
text editor or online. That will be faster than compiling Kicad.


https://github.com/KiCad/Resistors_SMD.pretty/blob/master/R_2512_HandSoldering.kicad_mod
https://github.com/KiCad/kicad-footprints/blob/master/Resistor_SMD.pretty/R_2512_6332Metric_Pad1.34x3.40mm_HandSolder.kicad_mod


On 4/04/18 09:56, Augusto Fraga Giachero wrote:

Sorry for the noise, I'll try to compile the Kicad 5 rc2 and check if
this issue persists in the new library.

Thanks,
Augusto Fraga Giachero.

Nick Østergaard writes:


The kicad-developers list is not really for detailed library discussions
like this. You may have better luck reporting the issue directly on
https://github.com/kicad/kicad-footprints/issues

I am not sure what the plan is, but I don't think the Librarians will
update the old footprints, all activity are done in the new repos.

http://kicad-pcb.org/post/kicad-official-libraries/

2018-04-03 23:33 GMT+02:00 Augusto Fraga Giachero :


Hi!

I've had a an unpleasant surprise with a 2512 (imperial) smd resistor
footprint (Resistors_SMD:R_2512_HandSoldering) available in the Kicad's
official library (shame on me for not checking the dimensions before
sending the gerbers). When our boards arrived we verified that the pads
of this footprint are too further apart, up to the point that the
resistor barely touches the pads.

I've looked on some datasheets and other sources and confirmed that this
footprint is out of the recommended dimensions
(http://www.resistorguide.com/resistor-sizes-and-packages/).

I've attached an image showing the dimensions from the website
above. The recommended dimensions for 2512 are a = 3.5mm, b = 1.6mm and
c = 3.8mm, while in the footprint available on Kicad a = 3.2mm, b =
2.7mm (no problems with this been wider as it is a hand soldering
variant) and c = 5.2mm.

Dim(mm) Average Kicad
a   3.5 3.2
b   1.6 2.7 (ok, hand soldering)
c   3.8 5.2 (too further apart)

I don't known if it is fixed in the new Kicad 5 libraries, but it would
be nice to be fixed in the legacy libraries as well. I can make the fix
if nobody have already made.

Thanks,
Augusto Fraga Giachero.


___
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] Alternative presentation of Symbol properties

[Jeff Young]

For the seldom-used stuff you can either go to the individual Edit Field 
dialog, or you can make more columns visible in the list (by right-clicking on 
the header).

> On 3 Apr 2018, at 08:18, Nick Østergaard  wrote:
> 
> Are you not missing a lot of properties from that dialog with your 
> screenshot, like the orientation? Or is this only to replace the "Fields" 
> frame of the dialog?
> 
> 2018-03-01 17:26 GMT+01:00 Jeff Young  >:
> Technically yes, but even the existing dialog only lets you edit both.
> 
> > On 1 Mar 2018, at 16:23, Andy Peters  > > wrote:
> >
> >
> >
> >> On Mar 1, 2018, at 5:29 AM, Jeff Young  >> > wrote:
> >>
> >> What do you guys think of this for displaying / editing symbol fields:
> >>
> >> 
> >
> > Don’t the text items have thickness and width attributes, not just one 
> > “size?”
> >
> > -a
> > ___
> > 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] Resistor 2512 footprint [Kicad 4.07]

[Augusto Fraga Giachero]

Sorry for the noise, I'll try to compile the Kicad 5 rc2 and check if
this issue persists in the new library.

Thanks,
Augusto Fraga Giachero.

Nick Østergaard writes:

> The kicad-developers list is not really for detailed library discussions
> like this. You may have better luck reporting the issue directly on
> https://github.com/kicad/kicad-footprints/issues
>
> I am not sure what the plan is, but I don't think the Librarians will
> update the old footprints, all activity are done in the new repos.
>
> http://kicad-pcb.org/post/kicad-official-libraries/
>
> 2018-04-03 23:33 GMT+02:00 Augusto Fraga Giachero :
>
>>
>> Hi!
>>
>> I've had a an unpleasant surprise with a 2512 (imperial) smd resistor
>> footprint (Resistors_SMD:R_2512_HandSoldering) available in the Kicad's
>> official library (shame on me for not checking the dimensions before
>> sending the gerbers). When our boards arrived we verified that the pads
>> of this footprint are too further apart, up to the point that the
>> resistor barely touches the pads.
>>
>> I've looked on some datasheets and other sources and confirmed that this
>> footprint is out of the recommended dimensions
>> (http://www.resistorguide.com/resistor-sizes-and-packages/).
>>
>> I've attached an image showing the dimensions from the website
>> above. The recommended dimensions for 2512 are a = 3.5mm, b = 1.6mm and
>> c = 3.8mm, while in the footprint available on Kicad a = 3.2mm, b =
>> 2.7mm (no problems with this been wider as it is a hand soldering
>> variant) and c = 5.2mm.
>>
>> Dim(mm) Average Kicad
>> a   3.5 3.2
>> b   1.6 2.7 (ok, hand soldering)
>> c   3.8 5.2 (too further apart)
>>
>> I don't known if it is fixed in the new Kicad 5 libraries, but it would
>> be nice to be fixed in the legacy libraries as well. I can make the fix
>> if nobody have already made.
>>
>> Thanks,
>> Augusto Fraga Giachero.
>>
>>
>> ___
>> 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] Resistor 2512 footprint [Kicad 4.07]

[Nick Østergaard]

The kicad-developers list is not really for detailed library discussions
like this. You may have better luck reporting the issue directly on
https://github.com/kicad/kicad-footprints/issues

I am not sure what the plan is, but I don't think the Librarians will
update the old footprints, all activity are done in the new repos.

http://kicad-pcb.org/post/kicad-official-libraries/

2018-04-03 23:33 GMT+02:00 Augusto Fraga Giachero :

>
> Hi!
>
> I've had a an unpleasant surprise with a 2512 (imperial) smd resistor
> footprint (Resistors_SMD:R_2512_HandSoldering) available in the Kicad's
> official library (shame on me for not checking the dimensions before
> sending the gerbers). When our boards arrived we verified that the pads
> of this footprint are too further apart, up to the point that the
> resistor barely touches the pads.
>
> I've looked on some datasheets and other sources and confirmed that this
> footprint is out of the recommended dimensions
> (http://www.resistorguide.com/resistor-sizes-and-packages/).
>
> I've attached an image showing the dimensions from the website
> above. The recommended dimensions for 2512 are a = 3.5mm, b = 1.6mm and
> c = 3.8mm, while in the footprint available on Kicad a = 3.2mm, b =
> 2.7mm (no problems with this been wider as it is a hand soldering
> variant) and c = 5.2mm.
>
> Dim(mm) Average Kicad
> a   3.5 3.2
> b   1.6 2.7 (ok, hand soldering)
> c   3.8 5.2 (too further apart)
>
> I don't known if it is fixed in the new Kicad 5 libraries, but it would
> be nice to be fixed in the legacy libraries as well. I can make the fix
> if nobody have already made.
>
> Thanks,
> Augusto Fraga Giachero.
>
>
> ___
> 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] Resistor 2512 footprint [Kicad 4.07]

[Augusto Fraga Giachero]

Hi!

I've had a an unpleasant surprise with a 2512 (imperial) smd resistor
footprint (Resistors_SMD:R_2512_HandSoldering) available in the Kicad's
official library (shame on me for not checking the dimensions before
sending the gerbers). When our boards arrived we verified that the pads
of this footprint are too further apart, up to the point that the
resistor barely touches the pads.

I've looked on some datasheets and other sources and confirmed that this
footprint is out of the recommended dimensions
(http://www.resistorguide.com/resistor-sizes-and-packages/).

I've attached an image showing the dimensions from the website
above. The recommended dimensions for 2512 are a = 3.5mm, b = 1.6mm and
c = 3.8mm, while in the footprint available on Kicad a = 3.2mm, b =
2.7mm (no problems with this been wider as it is a hand soldering
variant) and c = 5.2mm.

Dim(mm) Average Kicad
a   3.5 3.2
b   1.6 2.7 (ok, hand soldering)
c   3.8 5.2 (too further apart)

I don't known if it is fixed in the new Kicad 5 libraries, but it would
be nice to be fixed in the legacy libraries as well. I can make the fix
if nobody have already made.

Thanks,
Augusto Fraga Giachero.

___
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] Must tracks & vias of the same net be contiguous?

[Jeff Young]

More data:

1) The double SynchronizeNetsAndNetClasses() costs almost nothing.  We should 
leave it.

2) I did some testing having removed the second call to BuildConnectivity().  
It’s definitely faster; may or may not be risky.

3) I solved the insert performance penalty.  (Since files are /mostly/ in the 
right order, doing an insertion sort from the back is very fast.)

Thoughts on (2) appreciated.

Cheers,
Jeff.


> On 3 Apr 2018, at 18:58, Jeff Young  wrote:
> 
> We also call SynchronizeNetsAndNetClasses() twice (once in 
> NETINFO_LIST::buildListOfNets() and once immediately after returning from it).
> 
> 
>> On 3 Apr 2018, at 15:41, Jeff Young > 
>> wrote:
>> 
>> With the fix, TRACK::GetBestInsertPoint(BOARD*) takes 6.2% of a file load on 
>> a reasonably dense board.  
>> 
>> As points of comparison, BOARD::BuildConnectivity() takes 16.2% and 15.5%, 
>> and PCB_EDIT_FRAME::ReFillLayerWidget() 3.3%.
>> 
>> (We could of course have a faster and more resilient load if we added 
>> GetBestInsertPoint() but stopped calling BuildConnectivity() twice*.)
>> 
>> Cheers,
>> Jeff.
>> 
>> * Once from OpenProjectFiles() and once from OpenProjectFiles()/SetBoard().
>> 
>> 
>>> On 3 Apr 2018, at 14:48, Jeff Young >> > wrote:
>>> 
>>> The track/via insertion routines have two modes: blind-append and 
>>> insert-where-appropriate.  The board parser current relies on the file 
>>> being correct and uses append.  Changing it to insert fixes the bug.
>>> 
>>> I like this change because it makes us more resilient, and because it will 
>>> fix any other (unknown) bugs due to tracks not being grouped properly.
>>> 
>>> I don’t like this change because it will make board loading slower.
>>> 
>>> Another idea would be to keep track of tracks/vias as they come in, and 
>>> only do the sort if we find some out of order.  That’s definitely more 
>>> risky, though, and may not be much faster.
>>> 
>>> I’ll do some timings on a large board….
>>> 
 On 3 Apr 2018, at 14:36, Wayne Stambaugh > wrote:
 
 On 4/3/2018 9:29 AM, Tomasz Wlostowski wrote:
> On 03/04/18 15:13, Jeff Young wrote:
>> The clean-up algorithms depend on tracks & vias assigned to the same net 
>> to be grouped in the segment list.  Is that supposed to be guaranteed?
> 
> It is/used to be like this (there was/is a special sorting function,
> called at least in the TRACK_CLEANER). I would however rewrite the
> overlapping segment merging algorithm to not rely on the order of
> segments in the data structure. If nobody opposes I could give this a try.
> 
> Tom
 
 How much risk are we looking at?  Wouldn't it be more prudent to just
 ensure the sorting is performed before performing the track clean
 operation?  I would rather avoid creating any new issues this close to
 v5.  If we cannot avoid making the change, then we may just have to deal
 with it but I would rather that be the last option.
 
> 
> 
>> 
>> (I have a file where it is not the case.)
 
 I thought the sorting was always performed so that segments and vias
 would always be grouped by their net.  I'm not sure how a board file was
 created with an ungrouped segment.  @JP, care to comment on this?
 
>> ___
>> 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: 

Re: [Kicad-developers] JetBrains

[Wayne Stambaugh]

Mark,

I already ran into that so I guess at some point I will have to see if I
can fix this :(  It would be nice if the wxwidgets project would use a
build config method that works across platforms like pkg-config or cmake.

Wayne

On 4/3/2018 3:12 PM, Mark Roszko wrote:
> Wayne,
> 
> CLion will work with MSYS2 btw but the findwxwidgets script in kicad is
> broken and can't find the paths correctly because for some reason a
> define or two I've never narrowed down keep making it think its win32
> rather than msys2 with a unix tree. I think I normally butchered the
> script into submission when I was playing with it. But yea, expect that
> if you try.
> 

___
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] JetBrains

[Mark Roszko]

Wayne,

CLion will work with MSYS2 btw but the findwxwidgets script in kicad is
broken and can't find the paths correctly because for some reason a define
or two I've never narrowed down keep making it think its win32 rather than
msys2 with a unix tree. I think I normally butchered the script into
submission when I was playing with it. But yea, expect that if you try.
___
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] rc2

[Kevin Cozens]

On 2018-04-02 06:42 PM, Wayne Stambaugh wrote:

Things have quieted down quit a bit so we should be close to an rc2
release.  I saw a 3D viewer crash report but it looks like it might be a
video driver issue.  Are there any other outstanding issues we need to
fix before rc2 is tagged?


I am seeing a problem with CvPcb where it fails to show me any DIP package 
options when I select a 7400 IC on a board. I need to file a report about 
the problem.


--
Cheers!

Kevin.

http://www.ve3syb.ca/| "Nerds make the shiny things that
https://www.patreon.html/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] Must tracks & vias of the same net be contiguous?

[Jeff Young]

We also call SynchronizeNetsAndNetClasses() twice (once in 
NETINFO_LIST::buildListOfNets() and once immediately after returning from it).


> On 3 Apr 2018, at 15:41, Jeff Young  wrote:
> 
> With the fix, TRACK::GetBestInsertPoint(BOARD*) takes 6.2% of a file load on 
> a reasonably dense board.  
> 
> As points of comparison, BOARD::BuildConnectivity() takes 16.2% and 15.5%, 
> and PCB_EDIT_FRAME::ReFillLayerWidget() 3.3%.
> 
> (We could of course have a faster and more resilient load if we added 
> GetBestInsertPoint() but stopped calling BuildConnectivity() twice*.)
> 
> Cheers,
> Jeff.
> 
> * Once from OpenProjectFiles() and once from OpenProjectFiles()/SetBoard().
> 
> 
>> On 3 Apr 2018, at 14:48, Jeff Young > 
>> wrote:
>> 
>> The track/via insertion routines have two modes: blind-append and 
>> insert-where-appropriate.  The board parser current relies on the file being 
>> correct and uses append.  Changing it to insert fixes the bug.
>> 
>> I like this change because it makes us more resilient, and because it will 
>> fix any other (unknown) bugs due to tracks not being grouped properly.
>> 
>> I don’t like this change because it will make board loading slower.
>> 
>> Another idea would be to keep track of tracks/vias as they come in, and only 
>> do the sort if we find some out of order.  That’s definitely more risky, 
>> though, and may not be much faster.
>> 
>> I’ll do some timings on a large board….
>> 
>>> On 3 Apr 2018, at 14:36, Wayne Stambaugh >> > wrote:
>>> 
>>> On 4/3/2018 9:29 AM, Tomasz Wlostowski wrote:
 On 03/04/18 15:13, Jeff Young wrote:
> The clean-up algorithms depend on tracks & vias assigned to the same net 
> to be grouped in the segment list.  Is that supposed to be guaranteed?
 
 It is/used to be like this (there was/is a special sorting function,
 called at least in the TRACK_CLEANER). I would however rewrite the
 overlapping segment merging algorithm to not rely on the order of
 segments in the data structure. If nobody opposes I could give this a try.
 
 Tom
>>> 
>>> How much risk are we looking at?  Wouldn't it be more prudent to just
>>> ensure the sorting is performed before performing the track clean
>>> operation?  I would rather avoid creating any new issues this close to
>>> v5.  If we cannot avoid making the change, then we may just have to deal
>>> with it but I would rather that be the last option.
>>> 
 
 
> 
> (I have a file where it is not the case.)
>>> 
>>> I thought the sorting was always performed so that segments and vias
>>> would always be grouped by their net.  I'm not sure how a board file was
>>> created with an ungrouped segment.  @JP, care to comment on this?
>>> 
> ___
> 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   : 

Re: [Kicad-developers] Meson Build system

[Felipe Sanches]

yes it is great indeed.  I did experimentally port Inkscape to meson a few
weeks ago.

2018-04-03 14:13 GMT-03:00 Jakub Kozdon :

> Just found this on Linux Mint blog and it is looks promising -
> http://mesonbuild.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

[Kicad-developers] Meson Build system

[Jakub Kozdon]

Just found this on Linux Mint blog and it is looks promising - 
http://mesonbuild.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

Re: [Kicad-developers] rc2

[jp charras]

Le 03/04/2018 à 14:06, Wayne Stambaugh a écrit :
> On 4/3/2018 7:12 AM, jp charras wrote:
>> Le 03/04/2018 à 00:42, Wayne Stambaugh a écrit :
>>> Things have quieted down quit a bit so we should be close to an rc2
>>> release.  I saw a 3D viewer crash report but it looks like it might be a
>>> video driver issue.  Are there any other outstanding issues we need to
>>> fix before rc2 is tagged?  Please note, rc2 is going to be the UI string
>>> freeze so no UI string changes other than spelling errors after rc2.  If
>>> you have any UI string changes, now is the time.  Thanks again everyone
>>> for stepping up and squashing bugs for rc2.  Hopefully, there wont be a
>>> lot of critical bugs and we can roll out v5 by the end of April.
>>>
>>> Cheers,
>>>
>>> Wayne
>>
>> I know 2 non critical bugs, but annoying bugs, in Pcbnew:
>> 1 - In GAL mode, when selecting a zone outline (for instance to edit this 
>> zone parameters), and
>> deselecting it, it is always refilled, even if no change is made.
> 
> Is there a bug report filed against this?  How much effort is required
> to fix this?  The zone should not be refilled if no changes are made.

Not yet.
(I saw that recently, when trying to understand why each time I selected a zone 
outline for edit,
the Zone settings dialog took a while to be displayed for complex zones).

I am not so familiar with events management on GAL, and I'll leave a guy who 
has a better knowledge
of this code to fix this issue.

> 
>> 2 - The Footprint Wizard Library allows downloading and using libraries on 
>> Github.
>> It works only for V4 libraries.
>> Is is no longer compatible with the V5 footprint libraries on Github.
>> It can create serious mistakes for users.
>> (Perhaps the easy way is just to disable the Github library management)
>>
> 
> Now that I think about it, what is the downside to leaving the github
> plugin support in the wizard?  Some users may still want to keep their
> personal footprint libraries on github and continue to use the plugin.

At least, the user interface for the github support in the wizard should be 
modified.
V5 footprint libraries cannot be downloaded by the wizard, only V4 version.
This is due to the way the V5 libs are managed on Github, and this way is not 
compatible with the
current wizard (and the github plugin)

It should be clear for an user the wizard can download personnal libs, but no 
longer the official
kicad libs.

-- 
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] Must tracks & vias of the same net be contiguous?

[Jeff Young]

With the fix, TRACK::GetBestInsertPoint(BOARD*) takes 6.2% of a file load on a 
reasonably dense board.  

As points of comparison, BOARD::BuildConnectivity() takes 16.2% and 15.5%, and 
PCB_EDIT_FRAME::ReFillLayerWidget() 3.3%.

(We could of course have a faster and more resilient load if we added 
GetBestInsertPoint() but stopped calling BuildConnectivity() twice*.)

Cheers,
Jeff.

* Once from OpenProjectFiles() and once from OpenProjectFiles()/SetBoard().


> On 3 Apr 2018, at 14:48, Jeff Young  wrote:
> 
> The track/via insertion routines have two modes: blind-append and 
> insert-where-appropriate.  The board parser current relies on the file being 
> correct and uses append.  Changing it to insert fixes the bug.
> 
> I like this change because it makes us more resilient, and because it will 
> fix any other (unknown) bugs due to tracks not being grouped properly.
> 
> I don’t like this change because it will make board loading slower.
> 
> Another idea would be to keep track of tracks/vias as they come in, and only 
> do the sort if we find some out of order.  That’s definitely more risky, 
> though, and may not be much faster.
> 
> I’ll do some timings on a large board….
> 
>> On 3 Apr 2018, at 14:36, Wayne Stambaugh  wrote:
>> 
>> On 4/3/2018 9:29 AM, Tomasz Wlostowski wrote:
>>> On 03/04/18 15:13, Jeff Young wrote:
 The clean-up algorithms depend on tracks & vias assigned to the same net 
 to be grouped in the segment list.  Is that supposed to be guaranteed?
>>> 
>>> It is/used to be like this (there was/is a special sorting function,
>>> called at least in the TRACK_CLEANER). I would however rewrite the
>>> overlapping segment merging algorithm to not rely on the order of
>>> segments in the data structure. If nobody opposes I could give this a try.
>>> 
>>> Tom
>> 
>> How much risk are we looking at?  Wouldn't it be more prudent to just
>> ensure the sorting is performed before performing the track clean
>> operation?  I would rather avoid creating any new issues this close to
>> v5.  If we cannot avoid making the change, then we may just have to deal
>> with it but I would rather that be the last option.
>> 
>>> 
>>> 
 
 (I have a file where it is not the case.)
>> 
>> I thought the sorting was always performed so that segments and vias
>> would always be grouped by their net.  I'm not sure how a board file was
>> created with an ungrouped segment.  @JP, care to comment on this?
>> 
 ___
 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] Must tracks & vias of the same net be contiguous?

[Jeff Young]

The track/via insertion routines have two modes: blind-append and 
insert-where-appropriate.  The board parser current relies on the file being 
correct and uses append.  Changing it to insert fixes the bug.

I like this change because it makes us more resilient, and because it will fix 
any other (unknown) bugs due to tracks not being grouped properly.

I don’t like this change because it will make board loading slower.

Another idea would be to keep track of tracks/vias as they come in, and only do 
the sort if we find some out of order.  That’s definitely more risky, though, 
and may not be much faster.

I’ll do some timings on a large board….

> On 3 Apr 2018, at 14:36, Wayne Stambaugh  wrote:
> 
> On 4/3/2018 9:29 AM, Tomasz Wlostowski wrote:
>> On 03/04/18 15:13, Jeff Young wrote:
>>> The clean-up algorithms depend on tracks & vias assigned to the same net to 
>>> be grouped in the segment list.  Is that supposed to be guaranteed?
>> 
>> It is/used to be like this (there was/is a special sorting function,
>> called at least in the TRACK_CLEANER). I would however rewrite the
>> overlapping segment merging algorithm to not rely on the order of
>> segments in the data structure. If nobody opposes I could give this a try.
>> 
>> Tom
> 
> How much risk are we looking at?  Wouldn't it be more prudent to just
> ensure the sorting is performed before performing the track clean
> operation?  I would rather avoid creating any new issues this close to
> v5.  If we cannot avoid making the change, then we may just have to deal
> with it but I would rather that be the last option.
> 
>> 
>> 
>>> 
>>> (I have a file where it is not the case.)
> 
> I thought the sorting was always performed so that segments and vias
> would always be grouped by their net.  I'm not sure how a board file was
> created with an ungrouped segment.  @JP, care to comment on this?
> 
>>> ___
>>> 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] Must tracks & vias of the same net be contiguous?

[Wayne Stambaugh]

On 4/3/2018 9:29 AM, Tomasz Wlostowski wrote:
> On 03/04/18 15:13, Jeff Young wrote:
>> The clean-up algorithms depend on tracks & vias assigned to the same net to 
>> be grouped in the segment list.  Is that supposed to be guaranteed?
> 
> It is/used to be like this (there was/is a special sorting function,
> called at least in the TRACK_CLEANER). I would however rewrite the
> overlapping segment merging algorithm to not rely on the order of
> segments in the data structure. If nobody opposes I could give this a try.
> 
> Tom

How much risk are we looking at?  Wouldn't it be more prudent to just
ensure the sorting is performed before performing the track clean
operation?  I would rather avoid creating any new issues this close to
v5.  If we cannot avoid making the change, then we may just have to deal
with it but I would rather that be the last option.

> 
> 
>>
>> (I have a file where it is not the case.)

I thought the sorting was always performed so that segments and vias
would always be grouped by their net.  I'm not sure how a board file was
created with an ungrouped segment.  @JP, care to comment on this?

>> ___
>> 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] Must tracks & vias of the same net be contiguous?

[Tomasz Wlostowski]

On 03/04/18 15:13, Jeff Young wrote:
> The clean-up algorithms depend on tracks & vias assigned to the same net to 
> be grouped in the segment list.  Is that supposed to be guaranteed?

It is/used to be like this (there was/is a special sorting function,
called at least in the TRACK_CLEANER). I would however rewrite the
overlapping segment merging algorithm to not rely on the order of
segments in the data structure. If nobody opposes I could give this a try.

Tom


> 
> (I have a file where it is not the case.)
> ___
> 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] Must tracks & vias of the same net be contiguous?

[Jeff Young]

The clean-up algorithms depend on tracks & vias assigned to the same net to be 
grouped in the segment list.  Is that supposed to be guaranteed?

(I have a file where it is not the case.)
___
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] rc2

[Sergey A. Borshch]

On 03.04.2018 01:42, Wayne Stambaugh wrote:

Are there any other outstanding issues we need to
fix before rc2 is tagged?


https://bugs.launchpad.net/kicad/+bug/1678849
Today is one year since bug reported: opening eeschema in standalone mode 
ignores page layout description file setting. Changing any preference stored in 
project file causes page layout description file setting to get lost from project.


--
Regards,
  Sergey A. Borshchmailto: sb...@sourceforge.net
SB ELDI ltd. Riga, Latvia

___
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] rc2

[Wayne Stambaugh]

Adam,

Let's aim for some time this weekend.  If you run into issues, please
let me know and I can push it back until the macos packaging is ready.

Thanks,

Wayne

On 4/2/2018 8:22 PM, Adam Wolf wrote:
> We are making good progress on macOS packaging but are at least a few
> days away from something other folks can test.  Wanna aim for Friday for
> rc2?  It's probably a bit of a push for us Mac packagers but that's ok :)
> 
> Adam
> 
> On Mon, Apr 2, 2018, 5:43 PM Wayne Stambaugh  > wrote:
> 
> Things have quieted down quit a bit so we should be close to an rc2
> release.  I saw a 3D viewer crash report but it looks like it might be a
> video driver issue.  Are there any other outstanding issues we need to
> fix before rc2 is tagged?  Please note, rc2 is going to be the UI string
> freeze so no UI string changes other than spelling errors after rc2.  If
> you have any UI string changes, now is the time.  Thanks again everyone
> for stepping up and squashing bugs for rc2.  Hopefully, there wont be a
> lot of critical bugs and we can roll out v5 by the end of April.
> 
> Cheers,
> 
> Wayne
> 
> ___
> 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] rc2

[Wayne Stambaugh]

On 4/3/2018 7:12 AM, jp charras wrote:
> Le 03/04/2018 à 00:42, Wayne Stambaugh a écrit :
>> Things have quieted down quit a bit so we should be close to an rc2
>> release.  I saw a 3D viewer crash report but it looks like it might be a
>> video driver issue.  Are there any other outstanding issues we need to
>> fix before rc2 is tagged?  Please note, rc2 is going to be the UI string
>> freeze so no UI string changes other than spelling errors after rc2.  If
>> you have any UI string changes, now is the time.  Thanks again everyone
>> for stepping up and squashing bugs for rc2.  Hopefully, there wont be a
>> lot of critical bugs and we can roll out v5 by the end of April.
>>
>> Cheers,
>>
>> Wayne
> 
> I know 2 non critical bugs, but annoying bugs, in Pcbnew:
> 1 - In GAL mode, when selecting a zone outline (for instance to edit this 
> zone parameters), and
> deselecting it, it is always refilled, even if no change is made.

Is there a bug report filed against this?  How much effort is required
to fix this?  The zone should not be refilled if no changes are made.

> 2 - The Footprint Wizard Library allows downloading and using libraries on 
> Github.
> It works only for V4 libraries.
> Is is no longer compatible with the V5 footprint libraries on Github.
> It can create serious mistakes for users.
> (Perhaps the easy way is just to disable the Github library management)
> 

Now that I think about it, what is the downside to leaving the github
plugin support in the wizard?  Some users may still want to keep their
personal footprint libraries on github and continue to use the plugin.

___
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] rc2

[Wayne Stambaugh]

On 4/3/2018 7:33 AM, jp charras wrote:
> Le 03/04/2018 à 13:25, Maciej Sumiński a écrit :
>> On 04/03/2018 01:20 PM, Tomasz Wlostowski wrote:
>>> On 03/04/18 13:17, Nick Østergaard wrote:
 I think we should not disable the github plugin, but we may need to
 remove it from the wizard in a way that does not emphasize that this is
 the way to go. Maybe it is ok to remove it completely from the wizard,
 but just let the plugin in the fp-lib-table still work.
>>>
>>> I would rather disable it (with the possibility to re-enable in some
>>> config file for "hardcore" users). Over the last 3 years it brought us
>>> mostly troubles and no big advantage.
>>
>> I second that, the only potential issue we need to deal with is the
>> current plugin users. Once we remove the plugin, they will be stuck with
>> footprint libraries full of broken entries.
>>
>> For v6 we should simply provide a simple library updater taking
>> advantage of generic git interface (e.g. libgit), instead of tying
>> ourselves to Github.
>>
>> Cheers,
>> Orson
> 
> For V5, I was just talking about disabling github option in wizard only to 
> avoid issue.
> The github plugin is an other story.

Please disable it in the wizard only to prevent users from using the
legacy libraries.  Disabling the plugin completely will break existing
users fp-lib-table entries which is not acceptable.  Until we can
provide some type of migration tool, we will have to leave the github
plugin enabled.  Hopefully over time, users will slowly migrate away
from using the github plugin.

> 
> In V6, we will need a library updater for symbol libs, footprint libs, 3d 
> shapes libs, and perhaps
> some other things (python scripts for instance)
> 
> 

Maybe someone could create a git plugin to manage updating libraries.

___
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] rc2

[jp charras]

Le 03/04/2018 à 13:25, Maciej Sumiński a écrit :
> On 04/03/2018 01:20 PM, Tomasz Wlostowski wrote:
>> On 03/04/18 13:17, Nick Østergaard wrote:
>>> I think we should not disable the github plugin, but we may need to
>>> remove it from the wizard in a way that does not emphasize that this is
>>> the way to go. Maybe it is ok to remove it completely from the wizard,
>>> but just let the plugin in the fp-lib-table still work.
>>
>> I would rather disable it (with the possibility to re-enable in some
>> config file for "hardcore" users). Over the last 3 years it brought us
>> mostly troubles and no big advantage.
> 
> I second that, the only potential issue we need to deal with is the
> current plugin users. Once we remove the plugin, they will be stuck with
> footprint libraries full of broken entries.
> 
> For v6 we should simply provide a simple library updater taking
> advantage of generic git interface (e.g. libgit), instead of tying
> ourselves to Github.
> 
> Cheers,
> Orson

For V5, I was just talking about disabling github option in wizard only to 
avoid issue.
The github plugin is an other story.

In V6, we will need a library updater for symbol libs, footprint libs, 3d 
shapes libs, and perhaps
some other things (python scripts for instance)


-- 
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] rc2

[Maciej Sumiński]

On 04/03/2018 01:20 PM, Tomasz Wlostowski wrote:
> On 03/04/18 13:17, Nick Østergaard wrote:
>> I think we should not disable the github plugin, but we may need to
>> remove it from the wizard in a way that does not emphasize that this is
>> the way to go. Maybe it is ok to remove it completely from the wizard,
>> but just let the plugin in the fp-lib-table still work.
> 
> I would rather disable it (with the possibility to re-enable in some
> config file for "hardcore" users). Over the last 3 years it brought us
> mostly troubles and no big advantage.

I second that, the only potential issue we need to deal with is the
current plugin users. Once we remove the plugin, they will be stuck with
footprint libraries full of broken entries.

For v6 we should simply provide a simple library updater taking
advantage of generic git interface (e.g. libgit), instead of tying
ourselves to Github.

Cheers,
Orson



signature.asc
Description: OpenPGP digital signature
___
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] rc2

[Tomasz Wlostowski]

On 03/04/18 13:17, Nick Østergaard wrote:
> I think we should not disable the github plugin, but we may need to
> remove it from the wizard in a way that does not emphasize that this is
> the way to go. Maybe it is ok to remove it completely from the wizard,
> but just let the plugin in the fp-lib-table still work.

I would rather disable it (with the possibility to re-enable in some
config file for "hardcore" users). Over the last 3 years it brought us
mostly troubles and no big advantage.

Tom

___
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] rc2

[Nick Østergaard]

2018-04-03 13:12 GMT+02:00 jp charras :

> Le 03/04/2018 à 00:42, Wayne Stambaugh a écrit :
> > Things have quieted down quit a bit so we should be close to an rc2
> > release.  I saw a 3D viewer crash report but it looks like it might be a
> > video driver issue.  Are there any other outstanding issues we need to
> > fix before rc2 is tagged?  Please note, rc2 is going to be the UI string
> > freeze so no UI string changes other than spelling errors after rc2.  If
> > you have any UI string changes, now is the time.  Thanks again everyone
> > for stepping up and squashing bugs for rc2.  Hopefully, there wont be a
> > lot of critical bugs and we can roll out v5 by the end of April.
> >
> > Cheers,
> >
> > Wayne
>
> I know 2 non critical bugs, but annoying bugs, in Pcbnew:
> 1 - In GAL mode, when selecting a zone outline (for instance to edit this
> zone parameters), and
> deselecting it, it is always refilled, even if no change is made.
> 2 - The Footprint Wizard Library allows downloading and using libraries on
> Github.
> It works only for V4 libraries.
> Is is no longer compatible with the V5 footprint libraries on Github.
> It can create serious mistakes for users.
> (Perhaps the easy way is just to disable the Github library management)
>
>
> I think we should not disable the github plugin, but we may need to remove
it from the wizard in a way that does not emphasize that this is the way to
go. Maybe it is ok to remove it completely from the wizard, but just let
the plugin in the fp-lib-table still work.
___
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] rc2

[jp charras]

Le 03/04/2018 à 00:42, Wayne Stambaugh a écrit :
> Things have quieted down quit a bit so we should be close to an rc2
> release.  I saw a 3D viewer crash report but it looks like it might be a
> video driver issue.  Are there any other outstanding issues we need to
> fix before rc2 is tagged?  Please note, rc2 is going to be the UI string
> freeze so no UI string changes other than spelling errors after rc2.  If
> you have any UI string changes, now is the time.  Thanks again everyone
> for stepping up and squashing bugs for rc2.  Hopefully, there wont be a
> lot of critical bugs and we can roll out v5 by the end of April.
> 
> Cheers,
> 
> Wayne

I know 2 non critical bugs, but annoying bugs, in Pcbnew:
1 - In GAL mode, when selecting a zone outline (for instance to edit this zone 
parameters), and
deselecting it, it is always refilled, even if no change is made.
2 - The Footprint Wizard Library allows downloading and using libraries on 
Github.
It works only for V4 libraries.
Is is no longer compatible with the V5 footprint libraries on Github.
It can create serious mistakes for users.
(Perhaps the easy way is just to disable the Github library management)

-- 
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] Alternative presentation of Symbol properties

[Nick Østergaard]

Are you not missing a lot of properties from that dialog with your
screenshot, like the orientation? Or is this only to replace the "Fields"
frame of the dialog?

2018-03-01 17:26 GMT+01:00 Jeff Young :

> Technically yes, but even the existing dialog only lets you edit both.
>
> > On 1 Mar 2018, at 16:23, Andy Peters  wrote:
> >
> >
> >
> >> On Mar 1, 2018, at 5:29 AM, Jeff Young  wrote:
> >>
> >> What do you guys think of this for displaying / editing symbol fields:
> >>
> >> 
> >
> > Don’t the text items have thickness and width attributes, not just one
> “size?”
> >
> > -a
> > ___
> > 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