Re: [Kicad-developers] Eagle project import

2019-07-06 Thread Seth Hillbrand 

On 2019-07-06 17:16, Steven A. Falco wrote:

I am trying to import an Adafruit Eagle project into KiCAD 6 (built
from the current tip of the tree).

I placed a copy of the Eagle files and the conversion here:

https://www.dropbox.com/sh/6d5bqhsvwmjvta0/AACFjeWxfUAb73uTdmt5wNHNa?dl=0

The schematic looks pretty good, but there seems to be a problem with
filled zones in the pcb.  Specifically, there are a bunch of unrouted
traces, where vias should be connected to a zone.

Also, if I select "Show filled areas of zones", the zones remain as
just an outline rather than being colored in.  Am I doing something
wrong?  Do I need to adjust some parameter to get the zones to fill?



Nope.  This is a bug.  Nets are not propagating.  Can you file a report 
at the bug tracker so that we can address it?


If you need the circuit converted, it looks like 5.1.3 does the job 
correctly.


Best-
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

[Kicad-developers] Eagle project import

2019-07-06 Thread Steven A. Falco 
I am trying to import an Adafruit Eagle project into KiCAD 6 (built from the 
current tip of the tree).

I placed a copy of the Eagle files and the conversion here:

https://www.dropbox.com/sh/6d5bqhsvwmjvta0/AACFjeWxfUAb73uTdmt5wNHNa?dl=0

The schematic looks pretty good, but there seems to be a problem with filled 
zones in the pcb.  Specifically, there are a bunch of unrouted traces, where 
vias should be connected to a zone.

Also, if I select "Show filled areas of zones", the zones remain as just an 
outline rather than being colored in.  Am I doing something wrong?  Do I need 
to adjust some parameter to get the zones to fill?

Steve



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] [PATCH] Crash Reporter

2019-07-06 Thread Ian McInerney 
Tom,

Not to pile on the questions, but does the linux stack trace support exist
in the entire 3.0.x line, or how far back does it go? Currently, the
minimum version searched by cmake is 3.0.0, and some major linux distros
only have 3.0.2 (Debian Stable, EPEL6/7, and Ubuntu 16.04 to name a few).

-Ian

On Sat, Jul 6, 2019 at 8:57 PM Tomasz Wlostowski 
wrote:

> On 06/07/2019 09:04, Carsten Schoenert wrote:
> > Hi,
> >
> > Am 05.07.19 um 23:28 schrieb Ian McInerney:
> >> 3.1.x is essentially only available on the lesser-known distros and as
> >> additional packages for OpenSUSE. Aside from that, most distros run
> >> anything between 3.0.2 and 3.0.4. (see
> >> here: https://repology.org/project/wxwidgets/versions).
>
> Hi,
>
> wx 3.0.4 under Linux has stack trace support, so we don't need 3.1 for
> the crash reporter to work under Linux. wx 3.0.x under MSYS doesn't. I
> have no idea if it's a matter of build settings or just unimplemented
> feature, I'll have a look at this later in the eveing.
>
> 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
>
___
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] Crash Reporter

2019-07-06 Thread Tomasz Wlostowski 
On 06/07/2019 09:04, Carsten Schoenert wrote:
> Hi,
> 
> Am 05.07.19 um 23:28 schrieb Ian McInerney:
>> 3.1.x is essentially only available on the lesser-known distros and as
>> additional packages for OpenSUSE. Aside from that, most distros run
>> anything between 3.0.2 and 3.0.4. (see
>> here: https://repology.org/project/wxwidgets/versions).

Hi,

wx 3.0.4 under Linux has stack trace support, so we don't need 3.1 for
the crash reporter to work under Linux. wx 3.0.x under MSYS doesn't. I
have no idea if it's a matter of build settings or just unimplemented
feature, I'll have a look at this later in the eveing.

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

[Kicad-developers] "Tutorial" on modern toolset events & actions

2019-07-06 Thread Jeff Young 
OK, not really.  More of an “exercise left to the reader”.

I'm working through a bug that doesn’t reproduce on OSX, and so have been 
leaning on others (JP so far) to do a bit of sleuthing. One side-effect is that 
there is a lot of info in the bug report for people who aren’t familiar with 
the modern toolset.  Might be worth reading if you’re interested and haven’t 
been following it.

https://bugs.launchpad.net/kicad/+bug/1835083 
 ___
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 Board.GetAllNetClasses() so it no longer creates a duplicate of the Default netclass in the design rules net classes list.

2019-07-06 Thread Seth Hillbrand 

On 2019-07-06 10:17, Dave Vandenbout wrote:

Fixes: lp:1803623
* https://bugs.launchpad.net/kicad/+bug/1803623
---
 pcbnew/swig/board.i | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)



Looks good.  Thanks Dave!  Tests out on Python2 and Python3.

For my reference, why did you decide to copy element-wise instead of 
using .copy()?


-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

[Kicad-developers] [PATCH] Fix Board.GetAllNetClasses() so it no longer creates a duplicate of the Default netclass in the design rules net classes list.

2019-07-06 Thread Dave Vandenbout 

Fixes: lp:1803623
* https://bugs.launchpad.net/kicad/+bug/1803623
---
 pcbnew/swig/board.i | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/pcbnew/swig/board.i b/pcbnew/swig/board.i
index 91c41cc90..3bdc1e610 100644
--- a/pcbnew/swig/board.i
+++ b/pcbnew/swig/board.i
@@ -173,11 +173,10 @@ HANDLE_EXCEPTIONS(BOARD::TracksInNetBetweenPoints)
 GetNetClasses(BOARD self) -> { wxString net_class_name : NETCLASSPTR }
 Include the "Default" netclass also.
 """
-netclassmap = self.GetNetClasses().NetClasses()
 
-# Add the Default one too, but this is probably modifying the NETCLASS_MAP
-# in the BOARD.  If that causes trouble, could make a deepcopy() here first.
-# netclassmap = deepcopy(netclassmap)
+# Copy the NETCLASS_MAP so the one in the BOARD isn't modified
+# when we add the Default net class.
+netclassmap = {k:v for k,v in self.GetNetClasses().NetClasses().items()}
 netclassmap['Default'] = self.GetNetClasses().GetDefault()
 return netclassmap
 %}
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

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

2019-07-06 Thread Jeff Young 
I played with this a bit and I think we might want to reconsider.

The primary issue is that the point editor has a natural batching of 
operations: you select the zone, move a bunch of points around, and then 
deselect it.  We re-fill on deselect.

Moving items that overlap a zone has no such batching.  Refilling on each move 
(even when fills are fast) is pretty noisy.

So I’d be inclined to auto-fill ONLY after some points have been edited (and 
not on moving the zone or items which overlap it).

Thoughts?

Cheers,
Jeff.


> On 5 Jul 2019, at 17:13, Wayne Stambaugh  wrote:
> 
> On 7/5/19 11:50 AM, Seth Hillbrand wrote:
>> On 2019-07-05 07:46, Jeff Young wrote:
>>> 1) If I move a footprint which is over a zone, the zone fill becomes
>>> stale.
>>> 
>>> 2) If I move a zone which has footprints over it, the zone is re-filled.
>>> 
>>> 3) If I edit the points of a zone and then de-select it, the zone is
>>> re-filled.
>>> 
>>> Item (2) turns out to be a side effect of the PointEditor getting
>>> activated when the zone is selected for the move, and then refilling
>>> the zone when it is unselected.
>>> 
>>> Do we want to keep that, or should I make it consistent with (1)?
>>> 
>>> (Making it consistent will fix Wayne's crash, but I think I can find
>>> other ways of fixing it if we want to keep the behaviour.)
>> 
>> Wow, is that what that crash was?  Nice sleuthing there!  Point editor
>> is going to be the death of us. :)
>> 
>> Since we refill zones after they become stale internally, I think we
>> should be consistent and refill in case (1) also.  But this has some
>> nasty side effects when working in boards with extended fill times.  For
>> 5.1, I'd vote for leaving behavior as-is and adding a preference setting
>> for auto-refill stale zones in v6.  Then that can control all refills
>> including (1) as well as dragging a track over a filled zone area.
>> 
>> -Seth
>> 
> 
> I concur.  We should definitely make zone auto filling optional.  For
> complex boards the refill cost can be painful.
> 
> 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] [PATCH] Crash Reporter

2019-07-06 Thread Carsten Schoenert 
Hi,

Am 05.07.19 um 23:28 schrieb Ian McInerney:
> 3.1.x is essentially only available on the lesser-known distros and as
> additional packages for OpenSUSE. Aside from that, most distros run
> anything between 3.0.2 and 3.0.4. (see
> here: https://repology.org/project/wxwidgets/versions).

well, and that's for a simple reason Wayne has already written.

wxwidgets 3.0.x is the current version series marked as stable with no
API changes between releases.

And 3.1.x is the current development version of wxwidgets *with*
possible internal and external API modifications that make it hard for
distros to keep all depending packages in sync, it nearly impossible. So
no version 3.1.x is packaged in Debian at least for that reason. Not
even in experimental.

Once the API is set to frozen a new stable series of wxwidgets 3.2.x
will get released. Given the progress the wxwidgets development is
taking nobody can say a targeted date for a new stable release of wxwidgets.

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