Re: [Kicad-developers] [RFC] Experimental grid pattern in zone fill

[Nick Østergaard]

Just the other day a user on IRC showed us this image of a hexagonal fill
he hacked into his board by using bitmap2componet. Sort of a hack^3.

1) export gerbers and convert to PNG with gerbV
2) custom Python Imaging Library (PIL) script
3) bitmap2component

https://i.imgur.com/ThqIz5Y.png

Having native support in kicad is nicer. :) I don't imply we necessarely
need hexagonal fill pattern, this was just an example as inspiration.

In relation to the patch, is it not better to prefix the keyword token with
fill instead of grid?

Just a few comments on how it works in the copper zone properties. I know
you probably didn't invest too much time in this, but I will note it in
case you want some feedback to that. It looks like the combobox for the
fill style is empty when I try to open a zone. This is on an already
existing zone. It errors with a popup that the size and thickness does not
have the proper ratio. Maybe some defaults are needed here for usability.

2018-03-13 21:27 GMT+01:00 Jon Evans :

> OK, Makes sense.
>
> On Tue, Mar 13, 2018 at 4:25 PM, jp charras  wrote:
>
>> Le 13/03/2018 à 20:47, Jon Evans a écrit :
>> > I wonder if it might be a faster algorithm to calculate the perimeter
>> (and holes) of zones, offset
>> > it in by the zone thickness as a polygon, and then draw in the grid as
>> line segments rather than as
>> > more holes in the polygon?
>>
>> This is the first thing I tested. I abandoned this approach:
>> * It is not compatible with the current zone connectivity algo and the
>> current algo to remove
>> insulated islands.
>> * It can be very costly in drawing time because line segments can be very
>> numerous if the zone min
>> thickness is very small (because line segments must be set to this value
>> to be able to "fill" the
>> zone), much more the full polygon approach.
>> (try to fill a zone with a very small min thickness with segments)
>>
>> The zone as polygon is the best way for me.
>>
>> Removing holes in filled areas is not time consuming.
>> Removing not connected copper islands and the connectivity calculation is
>> more time consuming just
>> because there are more vertices.
>> This is also true when using 32 segments instead of 16 segments by circle.
>>
>> >
>> > On Tue, Mar 13, 2018 at 3:44 PM, jp charras > >
>> > wrote:
>> >
>> > Le 13/03/2018 à 20:38, Jon Evans a écrit :
>> > > For the last point, you could use the approach I put in GerbView
>> of start measuring the time, and
>> > > then throw up a progress window if the time exceeds N seconds
>> (with a button to cancel the operation)
>> > > That way you don't even see the window on small boards, but you
>> get the feedback and can cancel the
>> > > operation on large boards.
>> >
>> > Hi Jon,
>> > Filling zones has already this progress window.
>> > Grid pattern just can modify the calculation time due to more
>> vertices in zone outlines.
>> >
>> > >
>> > > On Tue, Mar 13, 2018 at 3:28 PM, jp charras <
>> jp.char...@wanadoo.fr
>> >  > >>
>> > > wrote:
>> > >
>> > > Le 13/03/2018 à 18:24, Seth Hillbrand a écrit :
>> > > > Hi JP-
>> > > >
>> > > > I gave it a spin and definitely like it!  I have been using
>> custom footprints for capacitive
>> > > > sensors, but this is much better.  A couple thoughts:
>> > > >
>> > > > 1) I'd prefer to have the angle saved as a parameter in the
>> file rather than a fixed list of options.
>> > >
>> > > Yes, good idea.
>> > >
>> > > > 2) We'll definitely need to address the polygon issue.  I
>> created a 10cmx10cm board and filled it
>> > > > with 45° at the minimum width/50% fill and my computer
>> froze for 2 minutes while it thought about
>> > > > it.  Strangely, when I checked it was only using one core,
>> so I'm not sure why the wm froze during
>> > > > the calculation.  Maybe some interaction with the graphics
>> card.
>> > > >
>> > >
>> > > Strange.
>> > > What is the zone setup?
>> > >
>> > > For basic boards, the fill zone calculation time is not
>> noticeable on my computer.
>> > > Noticeable calculation time (a few seconds) happens only for
>> *large* boards.
>> > >
>> > >
>> > > > If we can't fix the polygons before this, we should
>> probably have a dummy-check pop-up warning of
>> > > > long compute times.  The polygons get calculated twice on
>> closing the zone edit window.  Once with
>> > > > the cursor showing busy and then again with no indication
>> of work.  This happens again when
>> > > > highlighting.
>> > > >
>> > > > Best-
>> > > > Seth
>> > >
>> > > Trying to guess if the calculation time is 

Re: [Kicad-developers] [RFC] Experimental grid pattern in zone fill

[Jon Evans]

OK, Makes sense.

On Tue, Mar 13, 2018 at 4:25 PM, jp charras  wrote:

> Le 13/03/2018 à 20:47, Jon Evans a écrit :
> > I wonder if it might be a faster algorithm to calculate the perimeter
> (and holes) of zones, offset
> > it in by the zone thickness as a polygon, and then draw in the grid as
> line segments rather than as
> > more holes in the polygon?
>
> This is the first thing I tested. I abandoned this approach:
> * It is not compatible with the current zone connectivity algo and the
> current algo to remove
> insulated islands.
> * It can be very costly in drawing time because line segments can be very
> numerous if the zone min
> thickness is very small (because line segments must be set to this value
> to be able to "fill" the
> zone), much more the full polygon approach.
> (try to fill a zone with a very small min thickness with segments)
>
> The zone as polygon is the best way for me.
>
> Removing holes in filled areas is not time consuming.
> Removing not connected copper islands and the connectivity calculation is
> more time consuming just
> because there are more vertices.
> This is also true when using 32 segments instead of 16 segments by circle.
>
> >
> > On Tue, Mar 13, 2018 at 3:44 PM, jp charras  >
> > wrote:
> >
> > Le 13/03/2018 à 20:38, Jon Evans a écrit :
> > > For the last point, you could use the approach I put in GerbView
> of start measuring the time, and
> > > then throw up a progress window if the time exceeds N seconds
> (with a button to cancel the operation)
> > > That way you don't even see the window on small boards, but you
> get the feedback and can cancel the
> > > operation on large boards.
> >
> > Hi Jon,
> > Filling zones has already this progress window.
> > Grid pattern just can modify the calculation time due to more
> vertices in zone outlines.
> >
> > >
> > > On Tue, Mar 13, 2018 at 3:28 PM, jp charras  >   >>
> > > wrote:
> > >
> > > Le 13/03/2018 à 18:24, Seth Hillbrand a écrit :
> > > > Hi JP-
> > > >
> > > > I gave it a spin and definitely like it!  I have been using
> custom footprints for capacitive
> > > > sensors, but this is much better.  A couple thoughts:
> > > >
> > > > 1) I'd prefer to have the angle saved as a parameter in the
> file rather than a fixed list of options.
> > >
> > > Yes, good idea.
> > >
> > > > 2) We'll definitely need to address the polygon issue.  I
> created a 10cmx10cm board and filled it
> > > > with 45° at the minimum width/50% fill and my computer froze
> for 2 minutes while it thought about
> > > > it.  Strangely, when I checked it was only using one core,
> so I'm not sure why the wm froze during
> > > > the calculation.  Maybe some interaction with the graphics
> card.
> > > >
> > >
> > > Strange.
> > > What is the zone setup?
> > >
> > > For basic boards, the fill zone calculation time is not
> noticeable on my computer.
> > > Noticeable calculation time (a few seconds) happens only for
> *large* boards.
> > >
> > >
> > > > If we can't fix the polygons before this, we should probably
> have a dummy-check pop-up warning of
> > > > long compute times.  The polygons get calculated twice on
> closing the zone edit window.  Once with
> > > > the cursor showing busy and then again with no indication of
> work.  This happens again when
> > > > highlighting.
> > > >
> > > > Best-
> > > > Seth
> > >
> > > Trying to guess if the calculation time is long is really not
> easy.
> > >
> > >
> > > >
> > > > 2018-03-13 8:48 GMT-07:00 jp charras    > >
> > > 
>  >  > > >
> > > > Le 13/03/2018 à 14:05, Jon Evans a écrit :
> > > > > Nice work!  It may just be experimental, but it seems
> pretty close to a feature
> > for 6.0 to me :-)
> > > > > I gave it a try on various boards I have worked on
> recently and it seems to work
> > as advertised and
> > > > > is not noticeably slower than a solid fill on my
> computer.
> > > > >
> > > > > Assuming we work out any issues related to this, I
> thought of two features we
> > might want to add
> > > > > after this:
> > > > > 1) Allow 45-degree grids instead of just 90
> > > > > 2) Add a DRC check for stitching vias that would 

Re: [Kicad-developers] [RFC] Experimental grid pattern in zone fill

[jp charras]

Le 13/03/2018 à 20:47, Jon Evans a écrit :
> I wonder if it might be a faster algorithm to calculate the perimeter (and 
> holes) of zones, offset
> it in by the zone thickness as a polygon, and then draw in the grid as line 
> segments rather than as
> more holes in the polygon?

This is the first thing I tested. I abandoned this approach:
* It is not compatible with the current zone connectivity algo and the current 
algo to remove
insulated islands.
* It can be very costly in drawing time because line segments can be very 
numerous if the zone min
thickness is very small (because line segments must be set to this value to be 
able to "fill" the
zone), much more the full polygon approach.
(try to fill a zone with a very small min thickness with segments)

The zone as polygon is the best way for me.

Removing holes in filled areas is not time consuming.
Removing not connected copper islands and the connectivity calculation is more 
time consuming just
because there are more vertices.
This is also true when using 32 segments instead of 16 segments by circle.

> 
> On Tue, Mar 13, 2018 at 3:44 PM, jp charras  >
> wrote:
> 
> Le 13/03/2018 à 20:38, Jon Evans a écrit :
> > For the last point, you could use the approach I put in GerbView of 
> start measuring the time, and
> > then throw up a progress window if the time exceeds N seconds (with a 
> button to cancel the operation)
> > That way you don't even see the window on small boards, but you get the 
> feedback and can cancel the
> > operation on large boards.
> 
> Hi Jon,
> Filling zones has already this progress window.
> Grid pattern just can modify the calculation time due to more vertices in 
> zone outlines.
> 
> >
> > On Tue, Mar 13, 2018 at 3:28 PM, jp charras    >>
> > wrote:
> >
> >     Le 13/03/2018 à 18:24, Seth Hillbrand a écrit :
> >     > Hi JP-
> >     >
> >     > I gave it a spin and definitely like it!  I have been using 
> custom footprints for capacitive
> >     > sensors, but this is much better.  A couple thoughts:
> >     >
> >     > 1) I'd prefer to have the angle saved as a parameter in the file 
> rather than a fixed list of options.
> >
> >     Yes, good idea.
> >
> >     > 2) We'll definitely need to address the polygon issue.  I created 
> a 10cmx10cm board and filled it
> >     > with 45° at the minimum width/50% fill and my computer froze for 
> 2 minutes while it thought about
> >     > it.  Strangely, when I checked it was only using one core, so I'm 
> not sure why the wm froze during
> >     > the calculation.  Maybe some interaction with the graphics card.  
> >     >
> >
> >     Strange.
> >     What is the zone setup?
> >
> >     For basic boards, the fill zone calculation time is not noticeable 
> on my computer.
> >     Noticeable calculation time (a few seconds) happens only for 
> *large* boards.
> >
> >
> >     > If we can't fix the polygons before this, we should probably have 
> a dummy-check pop-up warning of
> >     > long compute times.  The polygons get calculated twice on closing 
> the zone edit window.  Once with
> >     > the cursor showing busy and then again with no indication of 
> work.  This happens again when
> >     > highlighting.
> >     >
> >     > Best-
> >     > Seth
> >
> >     Trying to guess if the calculation time is long is really not easy.
> >
> >
> >     >
> >     > 2018-03-13 8:48 GMT-07:00 jp charras    >
> >      
>   >     >
> >     >     Le 13/03/2018 à 14:05, Jon Evans a écrit :
> >     >     > Nice work!  It may just be experimental, but it seems 
> pretty close to a feature
> for 6.0 to me :-)
> >     >     > I gave it a try on various boards I have worked on recently 
> and it seems to work
> as advertised and
> >     >     > is not noticeably slower than a solid fill on my computer.
> >     >     >
> >     >     > Assuming we work out any issues related to this, I thought 
> of two features we
> might want to add
> >     >     > after this:
> >     >     > 1) Allow 45-degree grids instead of just 90
> >     >     > 2) Add a DRC check for stitching vias that would have 
> connected to a solid fill
> but are off-grid and
> >     >     > thus disconnected in grid fill?
> >     >     >
> >     >     > -Jon
> >     >
> >     >     Attached the experimental grid pattern in zone fill patch, 
> 

Re: [Kicad-developers] Why do current nightlies report that they are kicad 5.0.0-rc2?

[hauptmech]

I would not change anything. As long as your version increments as 
documented, there is no problem. But if you change that by jumping 
backwards, you create an exception that has the opportunity to bite people.


So what if you skipped RC1 in your version string (and therefore in your 
development sequence). It's just a number.


On 14/03/18 05:49, Wayne Stambaugh wrote:

To prevent version issues for packagers, I will remove the -rc2 tag from
the source repo and change the default (when git is not found) version
string to 5.0.0-rc1-unknown to indicate that the version is somewhere
between rc1 and rc2.  I don't know that this makes things any clearer or
not but I'm pretty sure no matter what we do, someone will be confused.
I'm not really interested in making the cmake version string code any
more complicated so unless there are some options to `git describe` that
would make things clearer, I'm going to stick with the current code.

On 3/13/2018 12:18 PM, Carsten Schoenert wrote:

Am 13.03.2018 um 17:05 schrieb Eeli Kaikkonen:

2018-03-13 17:44 GMT+02:00 Jon Evans :


I know what the G means, just wish git describe had an option to disable
it, since it makes copy/paste more tedious.

I think if we had left the tag at rc1, then we'd just have users thinking
they had rc1 when they really have a newer nightly. Better to make a new
tag that doesn't include rcN in it, or at least tries to make it a lot more
obvious that it isn't a RC version despite having those letters in the
string.


In a project where I took part in we solved a similar problem by using
{previous-tagged-version-number}+{version-control-reference}, for example
5.0RC1+gitX. We felt the plus sign is less ambiguous.

That would be the correct way and done by a lot of projects.

The now additional tag -rc2-dev makes it more difficult for
distributions to determine if a new version is available.

-rc2* is greater as -rc1 and I'd need to tune the watch file again in
Debian we use (and it's already a bit more complicated due the dfsg + rc
part). The added tag -rc2-dev solves nothing and shouldn't be used in
future situations.


___
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] [RFC] Experimental grid pattern in zone fill

[Jon Evans]

I wonder if it might be a faster algorithm to calculate the perimeter (and
holes) of zones, offset it in by the zone thickness as a polygon, and then
draw in the grid as line segments rather than as more holes in the polygon?

On Tue, Mar 13, 2018 at 3:44 PM, jp charras  wrote:

> Le 13/03/2018 à 20:38, Jon Evans a écrit :
> > For the last point, you could use the approach I put in GerbView of
> start measuring the time, and
> > then throw up a progress window if the time exceeds N seconds (with a
> button to cancel the operation)
> > That way you don't even see the window on small boards, but you get the
> feedback and can cancel the
> > operation on large boards.
>
> Hi Jon,
> Filling zones has already this progress window.
> Grid pattern just can modify the calculation time due to more vertices in
> zone outlines.
>
> >
> > On Tue, Mar 13, 2018 at 3:28 PM, jp charras  >
> > wrote:
> >
> > Le 13/03/2018 à 18:24, Seth Hillbrand a écrit :
> > > Hi JP-
> > >
> > > I gave it a spin and definitely like it!  I have been using custom
> footprints for capacitive
> > > sensors, but this is much better.  A couple thoughts:
> > >
> > > 1) I'd prefer to have the angle saved as a parameter in the file
> rather than a fixed list of options.
> >
> > Yes, good idea.
> >
> > > 2) We'll definitely need to address the polygon issue.  I created
> a 10cmx10cm board and filled it
> > > with 45° at the minimum width/50% fill and my computer froze for 2
> minutes while it thought about
> > > it.  Strangely, when I checked it was only using one core, so I'm
> not sure why the wm froze during
> > > the calculation.  Maybe some interaction with the graphics card.
> > >
> >
> > Strange.
> > What is the zone setup?
> >
> > For basic boards, the fill zone calculation time is not noticeable
> on my computer.
> > Noticeable calculation time (a few seconds) happens only for *large*
> boards.
> >
> >
> > > If we can't fix the polygons before this, we should probably have
> a dummy-check pop-up warning of
> > > long compute times.  The polygons get calculated twice on closing
> the zone edit window.  Once with
> > > the cursor showing busy and then again with no indication of
> work.  This happens again when
> > > highlighting.
> > >
> > > Best-
> > > Seth
> >
> > Trying to guess if the calculation time is long is really not easy.
> >
> >
> > >
> > > 2018-03-13 8:48 GMT-07:00 jp charras  
> > >>:
> > >
> > > Le 13/03/2018 à 14:05, Jon Evans a écrit :
> > > > Nice work!  It may just be experimental, but it seems pretty
> close to a feature for 6.0 to me :-)
> > > > I gave it a try on various boards I have worked on recently
> and it seems to work as advertised and
> > > > is not noticeably slower than a solid fill on my computer.
> > > >
> > > > Assuming we work out any issues related to this, I thought
> of two features we might want to add
> > > > after this:
> > > > 1) Allow 45-degree grids instead of just 90
> > > > 2) Add a DRC check for stitching vias that would have
> connected to a solid fill but are off-grid and
> > > > thus disconnected in grid fill?
> > > >
> > > > -Jon
> > >
> > > Attached the experimental grid pattern in zone fill patch,
> with 45 degree grid option.
> > >
> > > >
> > > > On Tue, Mar 13, 2018 at 4:10 AM, jp charras <
> jp.char...@wanadoo.fr 
> > > >
> > 
>  >  > > > wrote:
> > > >
> > > > I wrote a purely experimental option to fill zones
> (copper and not copper) with a grid patter.
> > > > It is only an experimental feature made mainly to know
> what issues can be created by this feature.
> > > >
> > > > The main issue is the fact polygons have much more
> corners, thus creating a longer calculation time.
> > > > (However, grid pattern is expected to be used in
> specific cases)
> > > >
> > > > It should be compatible with the current DRC.
> > > >
> > > > Regards
> > > >
> > > > --
> > > > Jean-Pierre CHARRAS
> >
> >
> >
> > --
> > Jean-Pierre CHARRAS
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers <
> https://launchpad.net/%7Ekicad-developers>
> > Post to : kicad-developers@lists.launchpad.net  

Re: [Kicad-developers] [RFC] Experimental grid pattern in zone fill

[jp charras]

Le 13/03/2018 à 20:38, Jon Evans a écrit :
> For the last point, you could use the approach I put in GerbView of start 
> measuring the time, and
> then throw up a progress window if the time exceeds N seconds (with a button 
> to cancel the operation)
> That way you don't even see the window on small boards, but you get the 
> feedback and can cancel the
> operation on large boards.

Hi Jon,
Filling zones has already this progress window.
Grid pattern just can modify the calculation time due to more vertices in zone 
outlines.

> 
> On Tue, Mar 13, 2018 at 3:28 PM, jp charras  >
> wrote:
> 
> Le 13/03/2018 à 18:24, Seth Hillbrand a écrit :
> > Hi JP-
> >
> > I gave it a spin and definitely like it!  I have been using custom 
> footprints for capacitive
> > sensors, but this is much better.  A couple thoughts:
> >
> > 1) I'd prefer to have the angle saved as a parameter in the file rather 
> than a fixed list of options.
> 
> Yes, good idea.
> 
> > 2) We'll definitely need to address the polygon issue.  I created a 
> 10cmx10cm board and filled it
> > with 45° at the minimum width/50% fill and my computer froze for 2 
> minutes while it thought about
> > it.  Strangely, when I checked it was only using one core, so I'm not 
> sure why the wm froze during
> > the calculation.  Maybe some interaction with the graphics card.  
> >
> 
> Strange.
> What is the zone setup?
> 
> For basic boards, the fill zone calculation time is not noticeable on my 
> computer.
> Noticeable calculation time (a few seconds) happens only for *large* 
> boards.
> 
> 
> > If we can't fix the polygons before this, we should probably have a 
> dummy-check pop-up warning of
> > long compute times.  The polygons get calculated twice on closing the 
> zone edit window.  Once with
> > the cursor showing busy and then again with no indication of work.  
> This happens again when
> > highlighting.
> >
> > Best-
> > Seth
> 
> Trying to guess if the calculation time is long is really not easy.
> 
> 
> >
> > 2018-03-13 8:48 GMT-07:00 jp charras  
> >>:
> >
> >     Le 13/03/2018 à 14:05, Jon Evans a écrit :
> >     > Nice work!  It may just be experimental, but it seems pretty 
> close to a feature for 6.0 to me :-)
> >     > I gave it a try on various boards I have worked on recently and 
> it seems to work as advertised and
> >     > is not noticeably slower than a solid fill on my computer.
> >     >
> >     > Assuming we work out any issues related to this, I thought of two 
> features we might want to add
> >     > after this:
> >     > 1) Allow 45-degree grids instead of just 90
> >     > 2) Add a DRC check for stitching vias that would have connected 
> to a solid fill but are off-grid and
> >     > thus disconnected in grid fill?
> >     >
> >     > -Jon
> >
> >     Attached the experimental grid pattern in zone fill patch, with 45 
> degree grid option.
> >
> >     >
> >     > On Tue, Mar 13, 2018 at 4:10 AM, jp charras 
> 
> >     >
>  
>   >     > wrote:
> >     >
> >     >     I wrote a purely experimental option to fill zones (copper 
> and not copper) with a grid patter.
> >     >     It is only an experimental feature made mainly to know what 
> issues can be created by this feature.
> >     >
> >     >     The main issue is the fact polygons have much more corners, 
> thus creating a longer calculation time.
> >     >     (However, grid pattern is expected to be used in specific 
> cases)
> >     >
> >     >     It should be compatible with the current DRC.
> >     >
> >     >     Regards
> >     >
> >     >     --
> >     >     Jean-Pierre CHARRAS
> 
> 
> 
> --
> 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 
> 
> 
> 


-- 
Jean-Pierre CHARRAS

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

Re: [Kicad-developers] [RFC] Experimental grid pattern in zone fill

[Jon Evans]

For the last point, you could use the approach I put in GerbView of start
measuring the time, and then throw up a progress window if the time exceeds
N seconds (with a button to cancel the operation)
That way you don't even see the window on small boards, but you get the
feedback and can cancel the operation on large boards.

On Tue, Mar 13, 2018 at 3:28 PM, jp charras  wrote:

> Le 13/03/2018 à 18:24, Seth Hillbrand a écrit :
> > Hi JP-
> >
> > I gave it a spin and definitely like it!  I have been using custom
> footprints for capacitive
> > sensors, but this is much better.  A couple thoughts:
> >
> > 1) I'd prefer to have the angle saved as a parameter in the file rather
> than a fixed list of options.
>
> Yes, good idea.
>
> > 2) We'll definitely need to address the polygon issue.  I created a
> 10cmx10cm board and filled it
> > with 45° at the minimum width/50% fill and my computer froze for 2
> minutes while it thought about
> > it.  Strangely, when I checked it was only using one core, so I'm not
> sure why the wm froze during
> > the calculation.  Maybe some interaction with the graphics card.
> >
>
> Strange.
> What is the zone setup?
>
> For basic boards, the fill zone calculation time is not noticeable on my
> computer.
> Noticeable calculation time (a few seconds) happens only for *large*
> boards.
>
>
> > If we can't fix the polygons before this, we should probably have a
> dummy-check pop-up warning of
> > long compute times.  The polygons get calculated twice on closing the
> zone edit window.  Once with
> > the cursor showing busy and then again with no indication of work.  This
> happens again when
> > highlighting.
> >
> > Best-
> > Seth
>
> Trying to guess if the calculation time is long is really not easy.
>
>
> >
> > 2018-03-13 8:48 GMT-07:00 jp charras >:
> >
> > Le 13/03/2018 à 14:05, Jon Evans a écrit :
> > > Nice work!  It may just be experimental, but it seems pretty close
> to a feature for 6.0 to me :-)
> > > I gave it a try on various boards I have worked on recently and it
> seems to work as advertised and
> > > is not noticeably slower than a solid fill on my computer.
> > >
> > > Assuming we work out any issues related to this, I thought of two
> features we might want to add
> > > after this:
> > > 1) Allow 45-degree grids instead of just 90
> > > 2) Add a DRC check for stitching vias that would have connected to
> a solid fill but are off-grid and
> > > thus disconnected in grid fill?
> > >
> > > -Jon
> >
> > Attached the experimental grid pattern in zone fill patch, with 45
> degree grid option.
> >
> > >
> > > On Tue, Mar 13, 2018 at 4:10 AM, jp charras  >   >>
> > > wrote:
> > >
> > > I wrote a purely experimental option to fill zones (copper and
> not copper) with a grid patter.
> > > It is only an experimental feature made mainly to know what
> issues can be created by this feature.
> > >
> > > The main issue is the fact polygons have much more corners,
> thus creating a longer calculation time.
> > > (However, grid pattern is expected to be used in specific
> cases)
> > >
> > > It should be compatible with the current DRC.
> > >
> > > Regards
> > >
> > > --
> > > Jean-Pierre CHARRAS
>
>
>
> --
> 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
>
___
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] [RFC] Experimental grid pattern in zone fill

[jp charras]

Le 13/03/2018 à 18:24, Seth Hillbrand a écrit :
> Hi JP-
> 
> I gave it a spin and definitely like it!  I have been using custom footprints 
> for capacitive
> sensors, but this is much better.  A couple thoughts:
> 
> 1) I'd prefer to have the angle saved as a parameter in the file rather than 
> a fixed list of options.

Yes, good idea.

> 2) We'll definitely need to address the polygon issue.  I created a 10cmx10cm 
> board and filled it
> with 45° at the minimum width/50% fill and my computer froze for 2 minutes 
> while it thought about
> it.  Strangely, when I checked it was only using one core, so I'm not sure 
> why the wm froze during
> the calculation.  Maybe some interaction with the graphics card.  
> 

Strange.
What is the zone setup?

For basic boards, the fill zone calculation time is not noticeable on my 
computer.
Noticeable calculation time (a few seconds) happens only for *large* boards.


> If we can't fix the polygons before this, we should probably have a 
> dummy-check pop-up warning of
> long compute times.  The polygons get calculated twice on closing the zone 
> edit window.  Once with
> the cursor showing busy and then again with no indication of work.  This 
> happens again when
> highlighting.
> 
> Best-
> Seth

Trying to guess if the calculation time is long is really not easy.


> 
> 2018-03-13 8:48 GMT-07:00 jp charras  >:
> 
> Le 13/03/2018 à 14:05, Jon Evans a écrit :
> > Nice work!  It may just be experimental, but it seems pretty close to a 
> feature for 6.0 to me :-)
> > I gave it a try on various boards I have worked on recently and it 
> seems to work as advertised and
> > is not noticeably slower than a solid fill on my computer.
> >
> > Assuming we work out any issues related to this, I thought of two 
> features we might want to add
> > after this:
> > 1) Allow 45-degree grids instead of just 90
> > 2) Add a DRC check for stitching vias that would have connected to a 
> solid fill but are off-grid and
> > thus disconnected in grid fill?
> >
> > -Jon
> 
> Attached the experimental grid pattern in zone fill patch, with 45 degree 
> grid option.
> 
> >
> > On Tue, Mar 13, 2018 at 4:10 AM, jp charras    >>
> > wrote:
> >
> >     I wrote a purely experimental option to fill zones (copper and not 
> copper) with a grid patter.
> >     It is only an experimental feature made mainly to know what issues 
> can be created by this feature.
> >
> >     The main issue is the fact polygons have much more corners, thus 
> creating a longer calculation time.
> >     (However, grid pattern is expected to be used in specific cases)
> >
> >     It should be compatible with the current DRC.
> >
> >     Regards
> >
> >     --
> >     Jean-Pierre CHARRAS



-- 
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] [RFC] Experimental grid pattern in zone fill

[Seth Hillbrand]

Hi JP-

I gave it a spin and definitely like it!  I have been using custom
footprints for capacitive sensors, but this is much better.  A couple
thoughts:

1) I'd prefer to have the angle saved as a parameter in the file rather
than a fixed list of options.
2) We'll definitely need to address the polygon issue.  I created a
10cmx10cm board and filled it with 45° at the minimum width/50% fill and my
computer froze for 2 minutes while it thought about it.  Strangely, when I
checked it was only using one core, so I'm not sure why the wm froze during
the calculation.  Maybe some interaction with the graphics card.

If we can't fix the polygons before this, we should probably have a
dummy-check pop-up warning of long compute times.  The polygons get
calculated twice on closing the zone edit window.  Once with the cursor
showing busy and then again with no indication of work.  This happens again
when highlighting.

Best-
Seth

2018-03-13 8:48 GMT-07:00 jp charras :

> Le 13/03/2018 à 14:05, Jon Evans a écrit :
> > Nice work!  It may just be experimental, but it seems pretty close to a
> feature for 6.0 to me :-)
> > I gave it a try on various boards I have worked on recently and it seems
> to work as advertised and
> > is not noticeably slower than a solid fill on my computer.
> >
> > Assuming we work out any issues related to this, I thought of two
> features we might want to add
> > after this:
> > 1) Allow 45-degree grids instead of just 90
> > 2) Add a DRC check for stitching vias that would have connected to a
> solid fill but are off-grid and
> > thus disconnected in grid fill?
> >
> > -Jon
>
> Attached the experimental grid pattern in zone fill patch, with 45 degree
> grid option.
>
> >
> > On Tue, Mar 13, 2018 at 4:10 AM, jp charras  >
> > wrote:
> >
> > I wrote a purely experimental option to fill zones (copper and not
> copper) with a grid patter.
> > It is only an experimental feature made mainly to know what issues
> can be created by this feature.
> >
> > The main issue is the fact polygons have much more corners, thus
> creating a longer calculation time.
> > (However, grid pattern is expected to be used in specific cases)
> >
> > It should be compatible with the current DRC.
> >
> > Regards
> >
> > --
> > Jean-Pierre CHARRAS
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers <
> https://launchpad.net/%7Ekicad-developers>
> > Post to : kicad-developers@lists.launchpad.net  kicad-developers@lists.launchpad.net>
> > Unsubscribe : https://launchpad.net/~kicad-developers <
> https://launchpad.net/%7Ekicad-developers>
> > More help   : https://help.launchpad.net/ListHelp <
> https://help.launchpad.net/ListHelp>
> >
> >
>
>
> --
> 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
>
>
___
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] Why do current nightlies report that they are kicad 5.0.0-rc2?

[Wayne Stambaugh]

To prevent version issues for packagers, I will remove the -rc2 tag from
the source repo and change the default (when git is not found) version
string to 5.0.0-rc1-unknown to indicate that the version is somewhere
between rc1 and rc2.  I don't know that this makes things any clearer or
not but I'm pretty sure no matter what we do, someone will be confused.
I'm not really interested in making the cmake version string code any
more complicated so unless there are some options to `git describe` that
would make things clearer, I'm going to stick with the current code.

On 3/13/2018 12:18 PM, Carsten Schoenert wrote:
> Am 13.03.2018 um 17:05 schrieb Eeli Kaikkonen:
>> 2018-03-13 17:44 GMT+02:00 Jon Evans :
>>
>>> I know what the G means, just wish git describe had an option to disable
>>> it, since it makes copy/paste more tedious.
>>>
>>> I think if we had left the tag at rc1, then we'd just have users thinking
>>> they had rc1 when they really have a newer nightly. Better to make a new
>>> tag that doesn't include rcN in it, or at least tries to make it a lot more
>>> obvious that it isn't a RC version despite having those letters in the
>>> string.
>>>
>> In a project where I took part in we solved a similar problem by using
>> {previous-tagged-version-number}+{version-control-reference}, for example
>> 5.0RC1+gitX. We felt the plus sign is less ambiguous.
> 
> That would be the correct way and done by a lot of projects.
> 
> The now additional tag -rc2-dev makes it more difficult for
> distributions to determine if a new version is available.
> 
> -rc2* is greater as -rc1 and I'd need to tune the watch file again in
> Debian we use (and it's already a bit more complicated due the dfsg + rc
> part). The added tag -rc2-dev solves nothing and shouldn't be used in
> future situations.
> 

___
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] who's responsible for translations?

[Wayne Stambaugh]

The source translations are managed here:

https://github.com/KiCad/kicad-i18n

On 3/13/2018 12:43 PM, Tomasz Wlostowski wrote:
> Hi all,
> 
> Sorry for a possibly dumb question - I've been recently contacted by a
> Polish translator who localized the V5 RC and submitted his
> contributions to me. Who is officially responsible for managing
> translations of KiCad so that I could forward this stuff to appropriate
> person?
> 
> Cheers,
> 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

[Kicad-developers] who's responsible for translations?

[Tomasz Wlostowski]

Hi all,

Sorry for a possibly dumb question - I've been recently contacted by a
Polish translator who localized the V5 RC and submitted his
contributions to me. Who is officially responsible for managing
translations of KiCad so that I could forward this stuff to appropriate
person?

Cheers,
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] Making typed-in unit support more obvious

[Seth Hillbrand]

Thanks!

Chris, your example link is dead but I'll use my imagination here.

1) I like the idea of making it more obvious.  For 5, could we just add a
tooltip?

2) I think that the extra step of only selecting the number is extraneous.
Since we default to the document units, it doesn't matter if the user
removes the units when typing.

3) Long term, I like the way SolidWorks handles this issue (see attached).
When there are no units in the box, it adds a drop-down underneath that
shows which units it accepts.  When there are valid units, the box is not
shown.  When there are invalid units the text color changes.  Right now, we
simply ignore units that are mistyped or that we don't know.

-S


2018-03-13 9:18 GMT-07:00 Jeff Young :

> Hi Seth,
>
> https://bugs.launchpad.net/kicad/+bug/1660156
>
> Cheers,
> Jeff.
>
>
> On 13 Mar 2018, at 15:39, Seth Hillbrand  wrote:
>
> Hi Jeff-
>
> I can't find which bug report this can you send the link?  I'm not sure
> that I follow what the issue is and I'd like to understand the problem it's
> addressing.
>
> Thanks!
> -S
>
> 2018-03-13 2:58 GMT-07:00 Jeff Young :
>
>> There’s a wishlish item to make support for typed-in units more
>> discoverable.
>>
>> I think the easiest way to do this is to adopt a policy of removing unit
>> static-texts following a value textCtrl in favour of displaying the current
>> units in the text.
>>
>> If the user clicks into the control and types only a number, we’ll assume
>> current units and display them with the value when the textCtrl loses focus.
>>
>> We already have all the code to support this.  I can clean up existing
>> dialogs when I fix them for the eradication of g_UserUnit.
>>
>> Thoughts?
>> ___
>> 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] Why do current nightlies report that they are kicad 5.0.0-rc2?

[Carsten Schoenert]

Am 13.03.2018 um 17:05 schrieb Eeli Kaikkonen:
> 2018-03-13 17:44 GMT+02:00 Jon Evans :
> 
>> I know what the G means, just wish git describe had an option to disable
>> it, since it makes copy/paste more tedious.
>>
>> I think if we had left the tag at rc1, then we'd just have users thinking
>> they had rc1 when they really have a newer nightly. Better to make a new
>> tag that doesn't include rcN in it, or at least tries to make it a lot more
>> obvious that it isn't a RC version despite having those letters in the
>> string.
>>
> In a project where I took part in we solved a similar problem by using
> {previous-tagged-version-number}+{version-control-reference}, for example
> 5.0RC1+gitX. We felt the plus sign is less ambiguous.

That would be the correct way and done by a lot of projects.

The now additional tag -rc2-dev makes it more difficult for
distributions to determine if a new version is available.

-rc2* is greater as -rc1 and I'd need to tune the watch file again in
Debian we use (and it's already a bit more complicated due the dfsg + rc
part). The added tag -rc2-dev solves nothing and shouldn't be used in
future situations.

-- 
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] Making typed-in unit support more obvious

[Jeff Young]

Hi Seth,

https://bugs.launchpad.net/kicad/+bug/1660156 


Cheers,
Jeff.


> On 13 Mar 2018, at 15:39, Seth Hillbrand  wrote:
> 
> Hi Jeff-
> 
> I can't find which bug report this can you send the link?  I'm not sure that 
> I follow what the issue is and I'd like to understand the problem it's 
> addressing.
> 
> Thanks!
> -S
> 
> 2018-03-13 2:58 GMT-07:00 Jeff Young >:
> There’s a wishlish item to make support for typed-in units more discoverable.
> 
> I think the easiest way to do this is to adopt a policy of removing unit 
> static-texts following a value textCtrl in favour of displaying the current 
> units in the text.
> 
> If the user clicks into the control and types only a number, we’ll assume 
> current units and display them with the value when the textCtrl loses focus.
> 
> We already have all the code to support this.  I can clean up existing 
> dialogs when I fix them for the eradication of g_UserUnit.
> 
> Thoughts?
> ___
> 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] Why do current nightlies report that they are kicad 5.0.0-rc2?

[Eeli Kaikkonen]

2018-03-13 17:44 GMT+02:00 Jon Evans :

> I know what the G means, just wish git describe had an option to disable
> it, since it makes copy/paste more tedious.
>
> I think if we had left the tag at rc1, then we'd just have users thinking
> they had rc1 when they really have a newer nightly. Better to make a new
> tag that doesn't include rcN in it, or at least tries to make it a lot more
> obvious that it isn't a RC version despite having those letters in the
> string.
>
>
>
In a project where I took part in we solved a similar problem by using
{previous-tagged-version-number}+{version-control-reference}, for example
5.0RC1+gitX. We felt the plus sign is less ambiguous.

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

Re: [Kicad-developers] Why do current nightlies report that they are kicad 5.0.0-rc2?

[Jon Evans]

I know what the G means, just wish git describe had an option to disable
it, since it makes copy/paste more tedious.

I think if we had left the tag at rc1, then we'd just have users thinking
they had rc1 when they really have a newer nightly. Better to make a new
tag that doesn't include rcN in it, or at least tries to make it a lot more
obvious that it isn't a RC version despite having those letters in the
string.

-Jon

On Tue, Mar 13, 2018, 11:38 Nick Østergaard  wrote:

> I think it would have been better if the commit after 5.0.0-rc1 was not
> tagged 5.0.0-rc2-dev. Then the git describe would make more sense. It would
> indicate that it was based on the 5.0.0-rc1 with additional commits and its
> hash.
>
> The g stands for git according to the man page.
> https://git-scm.com/docs/git-describe (search for "-g").
>
> 2018-03-12 15:48 GMT+01:00 Wayne Stambaugh :
>
>> On 3/12/2018 10:40 AM, Steven A. Falco wrote:
>> > On 03/12/2018 10:23 AM, Jon Evans wrote:
>> >> I have seen multiple users who run nightlies think they have RC2
>> because they read "5.0.0-rc2" and stop reading after that :-)
>> >> Maybe we should switch the tag back to "5.0-dev" between RC releases?
>> >> I think all of us developers are going to look up the git hash anyway
>> to know exactly when a given version was built, so the "rc2-dev"
>> information isn't super necessary for me at least.
>> >>
>> >> By the way, it's probably annoying to change this because I imagine
>> there are scripts that depend on it, but I wish the git hash didn't have a
>> "g" in front of it, since if I just double-click that portion of the
>> version string I have to manually remove the "g" before pasting it
>> elsewhere to look up the hash.
>> >
>> > I agree that the -rc2 could be confusing.  As to the "g" prefix, that
>> is not present in the Fedora nightlies.  They report more like:
>> >
>> > 5.0.0-rc2-dev-unknown-r12328-8fcbb64a
>>
>> My bad.  I forgot that -unknown is append to the end of the version
>> string when building from a source archive or no git.  Every think
>> appended after that is done by the build script.
>>
>> >
>> > where the r12328 is a sequential number representing the number of
>> commits to date and the 8fcbb64a is the short SHA of the head commit.
>> >
>> >   Steve
>> >
>> >
>> > ___
>> > 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] Making typed-in unit support more obvious

[Seth Hillbrand]

Hi Jeff-

I can't find which bug report this can you send the link?  I'm not sure
that I follow what the issue is and I'd like to understand the problem it's
addressing.

Thanks!
-S

2018-03-13 2:58 GMT-07:00 Jeff Young :

> There’s a wishlish item to make support for typed-in units more
> discoverable.
>
> I think the easiest way to do this is to adopt a policy of removing unit
> static-texts following a value textCtrl in favour of displaying the current
> units in the text.
>
> If the user clicks into the control and types only a number, we’ll assume
> current units and display them with the value when the textCtrl loses focus.
>
> We already have all the code to support this.  I can clean up existing
> dialogs when I fix them for the eradication of g_UserUnit.
>
> Thoughts?
> ___
> 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] Why do current nightlies report that they are kicad 5.0.0-rc2?

[Nick Østergaard]

I think it would have been better if the commit after 5.0.0-rc1 was not
tagged 5.0.0-rc2-dev. Then the git describe would make more sense. It would
indicate that it was based on the 5.0.0-rc1 with additional commits and its
hash.

The g stands for git according to the man page.
https://git-scm.com/docs/git-describe (search for "-g").

2018-03-12 15:48 GMT+01:00 Wayne Stambaugh :

> On 3/12/2018 10:40 AM, Steven A. Falco wrote:
> > On 03/12/2018 10:23 AM, Jon Evans wrote:
> >> I have seen multiple users who run nightlies think they have RC2
> because they read "5.0.0-rc2" and stop reading after that :-)
> >> Maybe we should switch the tag back to "5.0-dev" between RC releases?
> >> I think all of us developers are going to look up the git hash anyway
> to know exactly when a given version was built, so the "rc2-dev"
> information isn't super necessary for me at least.
> >>
> >> By the way, it's probably annoying to change this because I imagine
> there are scripts that depend on it, but I wish the git hash didn't have a
> "g" in front of it, since if I just double-click that portion of the
> version string I have to manually remove the "g" before pasting it
> elsewhere to look up the hash.
> >
> > I agree that the -rc2 could be confusing.  As to the "g" prefix, that is
> not present in the Fedora nightlies.  They report more like:
> >
> > 5.0.0-rc2-dev-unknown-r12328-8fcbb64a
>
> My bad.  I forgot that -unknown is append to the end of the version
> string when building from a source archive or no git.  Every think
> appended after that is done by the build script.
>
> >
> > where the r12328 is a sequential number representing the number of
> commits to date and the 8fcbb64a is the short SHA of the head commit.
> >
> >   Steve
> >
> >
> > ___
> > 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] [RFC] Experimental grid pattern in zone fill

[Jon Evans]

Nice work!  It may just be experimental, but it seems pretty close to a
feature for 6.0 to me :-)
I gave it a try on various boards I have worked on recently and it seems to
work as advertised and is not noticeably slower than a solid fill on my
computer.

Assuming we work out any issues related to this, I thought of two features
we might want to add after this:
1) Allow 45-degree grids instead of just 90
2) Add a DRC check for stitching vias that would have connected to a solid
fill but are off-grid and thus disconnected in grid fill?

-Jon

On Tue, Mar 13, 2018 at 4:10 AM, jp charras  wrote:

> I wrote a purely experimental option to fill zones (copper and not copper)
> with a grid patter.
> It is only an experimental feature made mainly to know what issues can be
> created by this feature.
>
> The main issue is the fact polygons have much more corners, thus creating
> a longer calculation time.
> (However, grid pattern is expected to be used in specific cases)
>
> It should be compatible with the current DRC.
>
> Regards
>
> --
> 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
>
>
___
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 in numeric_evaluator?

[Jeff Young]

Ah, right, I misread it.  In the while condition isdigit() and isDecSep() will 
both return false for \0 and thereby exit the loop.  It’s just a typo 
introduced when the new isDecSep() was implemented.

That’s pretty funny that it works.

Thanks for the clarification, Michael.

Cheers,
Jeff.



> On 13 Mar 2018, at 11:44, Michael Geselbracht  wrote:
> 
> It is a bug/typo that just happens to work. There is no need to check for \0. 
> There used to be a comparison like "ch == clDecSep". Ugly but it should be 
> safe for now.
> 
> if( isDecSep( ch ) && sepCount )
>break;
> 
> should do the trick.
> 
>  - Michael
> 
> 
> On Tue, Mar 13, 2018 at 11:10 AM, Jeff Young  > wrote:
> Yuck.  It’s clever code all right.  The “correct” version would be:
> 
> if( !ch || ( isDecSep( ch ) && sepCount ) )
>break;
> 
> but it’s a whole 3 characters longer. ;)
> 
> I’ll fix this in my 6.0 tree (which already has libeval re-formatted to Kicad 
> standards), but I suggest we leave it sleeping for 5.0.
> 
> Cheers,
> Jeff.
> 
> 
>> On 13 Mar 2018, at 02:20, Jon Evans > > wrote:
>> 
>> +Michael
>> 
>> This looks like "clever" code so I can't tell if this is a bug or not 
>> without running through a bunch of test cases which I'm not going to do 
>> right now.
>> Do you see any issues with the operation of the code, Mark, or just the 
>> warning?
>> 
>> -Jon
>> 
>> On Mon, Mar 12, 2018 at 9:28 PM, Mark Roszko > > wrote:
>> Not sure where to even begin looking at libeval since it looks scary but 
>> MSVC complains:
>> 
>> D:\kicad-source-mirror\common\libeval\numeric_evaluator.cpp(216): warning 
>> C4805: '==': unsafe mix of type 'char' and type 'bool' in operation
>> 
>> which is:
>> 
>>   auto ch = clToken.input[clToken.pos];
>>   do {
>>  if (ch == isDecSep(ch) && sepCount) break;
>> 
>> 
>> ch is a char
>> 
>> isDecSep returns bool
>> 
>> char == bool?
>> 
>> 
>> 
>> -- 
>> Mark
>> 
>> ___
>> 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] Action python plugin: access to sch/net user fields

[Eldar Khayrullin]

Hi guys.
I wrote pcbnew action plugin for generating pos files.
This is applicable for Russia now (uses russian transliteration).

It is can easy changed for generating custom report files from pcb and 
sch.

This plugin reads user fields from sch.

https://github.com/KiCad-RU/kicad_plugins

В Воскресенье, 11 мар. 2018 в 2:09 П. П., 
eldar.khayrullin  написал:

Hi guys.
Is it possible to access to schematic user fields from action 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] bug in numeric_evaluator?

[Michael Geselbracht]

It is a bug/typo that just happens to work. There is no need to check for
\0. There used to be a comparison like "ch == clDecSep". Ugly but it should
be safe for now.

if( isDecSep( ch ) && sepCount )
   break;

should do the trick.

 - Michael


On Tue, Mar 13, 2018 at 11:10 AM, Jeff Young  wrote:

> Yuck.  It’s clever code all right.  The “correct” version would be:
>
> if( !ch || ( isDecSep( ch ) && sepCount ) )
>break;
>
> but it’s a whole 3 characters longer. ;)
>
> I’ll fix this in my 6.0 tree (which already has libeval re-formatted to
> Kicad standards), but I suggest we leave it sleeping for 5.0.
>
> Cheers,
> Jeff.
>
>
> On 13 Mar 2018, at 02:20, Jon Evans  wrote:
>
> +Michael
>
> This looks like "clever" code so I can't tell if this is a bug or not
> without running through a bunch of test cases which I'm not going to do
> right now.
> Do you see any issues with the operation of the code, Mark, or just the
> warning?
>
> -Jon
>
> On Mon, Mar 12, 2018 at 9:28 PM, Mark Roszko 
> wrote:
>
>> Not sure where to even begin looking at libeval since it looks scary but
>> MSVC complains:
>>
>> D:\kicad-source-mirror\common\libeval\numeric_evaluator.cpp(216):
>> warning C4805: '==': unsafe mix of type 'char' and type 'bool' in operation
>>
>> which is:
>>
>>   auto ch = clToken.input[clToken.pos];
>>   do {
>>  if (ch == isDecSep(ch) && sepCount) break;
>>
>>
>> ch is a char
>>
>> isDecSep returns bool
>>
>> char == bool?
>>
>>
>>
>> --
>> Mark
>>
>> ___
>> 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] KiCad 5 RC1 fails to build on armel (mips, powerpc and ppc64el due undeclared initializer LIBCONTEXT_CALL_CONVENTION)

[Carsten Schoenert]

Hi up there,

a small update for the issue on armel (armvt4, armvt5t).

Am 09.03.2018 um 07:45 schrieb Carsten Schoenert:
> PS: The build issue on armel is probably related to a missing '-mfpu=vfp
> -msoft-float' option or similar, I will try to reproduce this on one of
> my cubieboards. If someone has a quicker solution I'm also happy to try
> this out.
I added '-mthumb -mfloat-abi=soft -mfpu=neon' to CXXFLAGS and the build
was going till the end until the final big linking is done. And then ...
it fails again.

> [100%] Linking CXX shared module _pcbnew.kiface
> cd "/build/kicad-5.0.0~rc1+dfsg1/debian/build/pcbnew" && /usr/bin/cmake -E 
> cmake_link_script CMakeFiles/pcbnew_kiface.dir/link.txt --verbose=1
> /usr/lib/ccache/c++ -fPIC -Wall -g -O2 
> -fdebug-prefix-map=/build/kicad-5.0.0~rc1+dfsg1=. -fstack-protector-strong 
> -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -mthumb 
> -mfloat-abi=soft -mfpu=neon -Wdate-time -D_FORTIFY_
> SOURCE=2 -Wsuggest-override -Wno-unused-local-typedefs -Wno-strict-aliasing 
> -fopenmp -pthread -Wl,--no-undefined -Wl,-Bsymbolic -shared  -o 
> _pcbnew.kiface CMakeFiles/pcbnew_kiface.dir/pcbnew.cpp.o 
> CMakeFiles/pcbnew_kiface.dir/microwave/mi
> crowave_inductor.cpp.o 
> CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_SVG_print.cpp.o 
> CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_SVG_print_base.cpp.o 
> CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_block_options.cpp.o 
> CMakeFiles/pcbnew_kiface.d
> ...
> _tool.cpp.o CMakeFiles/pcbnew_kiface.dir/tools/footprint_editor_tools.cpp.o 
> CMakeFiles/pcbnew_kiface.dir/tools/pad_tool.cpp.o 
> CMakeFiles/pcbnew_kiface.dir/tools/pcb_actions.cpp.o 
> CMakeFiles/pcbnew_kiface.dir/tools/pcb_bright_box.cpp.o 
> CMakeFiles/pcbnew_kiface.dir/tools/pcb_editor_control.cpp.o 
> CMakeFiles/pcbnew_kiface.dir/tools/pcb_selection_conditions.cpp.o 
> CMakeFiles/pcbnew_kiface.dir/tools/pcb_tool.cpp.o 
> CMakeFiles/pcbnew_kiface.dir/tools/pcbnew_control.cpp.o 
> CMakeFiles/pcbnew_kiface.dir/tools/picker_tool.cpp.o 
> CMakeFiles/pcbnew_kiface.dir/tools/placement_tool.cpp.o 
> CMakeFiles/pcbnew_kiface.dir/tools/point_editor.cpp.o 
> CMakeFiles/pcbnew_kiface.dir/tools/position_relative_tool.cpp.o 
> CMakeFiles/pcbnew_kiface.dir/tools/selection.cpp.o 
> CMakeFiles/pcbnew_kiface.dir/tools/selection_tool.cpp.o 
> CMakeFiles/pcbnew_kiface.dir/tools/size_menu.cpp.o 
> CMakeFiles/pcbnew_kiface.dir/tools/tool_event_utils.cpp.o 
> CMakeFiles/pcbnew_kiface.dir/tools/tools_common.cpp.o 
> CMakeFiles/pcbnew_kiface.dir/tools/zone_create_helper.cpp.o 
> CMakeFiles/pcbnew_kiface.dir/tools/zone_filler_tool.cpp.o 
> CMakeFiles/pcbnew_kiface.dir/footprint_preview_panel.cpp.o 
> CMakeFiles/pcbnew_kiface.dir/__/common/dialogs/dialog_page_settings.cpp.o 
> CMakeFiles/pcbnew_kiface.dir/__/common/base_units.cpp.o 
> CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_scripting.cpp.o 
> CMakeFiles/pcbnew_kiface.dir/dialogs/dialog_scripting_base.cpp.o 
> CMakeFiles/pcbnew_kiface.dir/pcbnew_wrap.cxx.o 
> CMakeFiles/pcbnew_kiface.dir/__/common/swig/wx_python_helpers.cpp.o 
> CMakeFiles/pcbnew_kiface.dir/swig/pcbnew_action_plugins.cpp.o 
> CMakeFiles/pcbnew_kiface.dir/swig/pcbnew_footprint_wizards.cpp.o 
> CMakeFiles/pcbnew_kiface.dir/swig/pcbnew_scripting_helpers.cpp.o 
> CMakeFiles/pcbnew_kiface.dir/swig/python_scripting.cpp.o 
> -Wl,-rpath,"/build/kicad-5.0.0~rc1+dfsg1/debian/build/3d-viewer/3d_cache/sg:" 
> ../3d-viewer/lib3d-viewer.a ../common/libpcbcommon.a router/libpnsrouter.a 
> pcad2kicadpcb_plugin/libpcad2kicadpcb.a ../common/libcommon.a 
> ../polygon/libpolygon.a ../bitmaps_png/libbitmaps.a ../common/libgal.a 
> ../lib_dxf/liblib_dxf.a ../utils/idftools/libidf3.a 
> -L/usr/lib/arm-linux-gnueabi -pthread -lwx_gtk2u_gl-3.0 -lwx_gtk2u_aui-3.0 
> -lwx_gtk2u_adv-3.0 -lwx_gtk2u_html-3.0 -lwx_gtk2u_core-3.0 -lwx_baseu_net-3.0 
> -lwx_baseu-3.0 -lwx_baseu_xml-3.0 -lwx_gtk2u_stc-3.0 
> github/libgithub_plugin.a -lpython2.7 -lrt 
> ../3d-viewer/3d_cache/sg/libkicad_3dsg.so.2.0.0 -L/usr/lib/arm-linux-gnueabi 
> -pthread -lwx_gtk2u_gl-3.0 -lwx_gtk2u_aui-3.0 -lwx_gtk2u_adv-3.0 
> -lwx_gtk2u_html-3.0 -lwx_gtk2u_core-3.0 -lwx_baseu_net-3.0 -lwx_baseu-3.0 
> -lwx_baseu_xml-3.0 -lwx_gtk2u_stc-3.0 ../common/libcommon.a 
> ../common/libgal.a -lGLEW -lcairo -lpixman-1 -lGL -lGLU -lcurl -lssl -lcrypto
> CMakeFiles/pcbnew_kiface.dir/pcbnew.cpp.o: In function 
> `_GLOBAL__sub_I_pcbnew.cpp':
> ./debian/build/pcbnew/./pcbnew/pcbnew.cpp:312:(.text.startup+0x1ae): 
> relocation truncated to fit: R_ARM_THM_CALL against symbol 
> `FP_LIB_TABLE::FP_LIB_TABLE(FP_LIB_TABLE*)' defined in .text section in 
> ../common/libpcbcommon.a(fp_lib_table.cpp.o)
> collect2: error: ld returned 1 exit status 
> pcbnew/CMakeFiles/pcbnew_kiface.dir/build.make:6808: recipe for target 
> 'pcbnew/_pcbnew.kiface' failed
> make[3]: *** [pcbnew/_pcbnew.kiface] Error 1
> make[3]: Leaving directory '/build/kicad-5.0.0~rc1+dfsg1/debian/build'
> CMakeFiles/Makefile2:1573: recipe for target 
> 

Re: [Kicad-developers] Need guidance/hints on accessing list of available pcbnew footprints from python

[Maciej Sumiński]

Hi Miles,

Have you seen FOOTPRINT_VIEWER_FRAME::ReCreateFootprintList()
(pcbnew/footprint_viewer_frame.cpp)? It might be the easiest way to go.
Perhaps it could be wrapped in a function provided by the scripting
interface.

I could not find 'includefallback' option you have mentioned, would you
point me to the relevant source code?

Regards,
Orson

On 03/13/2018 10:49 AM, miles mccoo wrote:
> In one of my python plugins, I want to know the list of available
> footprints (mounting holes, in this case)
> 
> Digging through the code, I can't make heads or tails of how to get this
> information. There are a bunch of abstract class involved. impls
> 
> There are a couple possibilities, none of which seem clean.
> 
> *Stuff from FOOTPRINT plugin*
> looking in footprint.i, I see some APIs that are close.
> If I have a directory path to a fp library, I can
> call pcbnew.FootprintEnumerate for a nice list.
> 
> but for that, I first have to have a list of fp library paths. *How do I
> get such a list? *This seems like the closest answer. I see my config dir
> has a fp-lib-table file which would be easy to parse. But that's a hack.
> 
> 
> 
> *FOOTPRINT_LIST_IMPL possibility*
> looking in load_select_footprint, I see it has a static FOOTPRINT_LIST_IMPL
> which does have the APIs I'd need to get to a nice list of footprint_infos.
> But it's static to that file. I could copy the relevant code to
> python_scripting_helpers. but that feels messy.
> 
> PCB_BASE_FRAME does have a method for popping up a table for a user to
> choose a footprint, which is nice for UI. It could even be useful for
> python plugins with some GUI stuff. But many python scripts will just want
> a list of libraries and modules.
> 
> 
> 
> *PROJECT possibility*
> I tried exposing PROJECT to python as it has a number of useful sounding
> API including PcbFootprintLibs which returns a FP_LIB_TABLE. By poking
> around in gdb, I see that FP_LIB_TABLE has GetCount and IsEmpty. IsEmpty
> returns false if I set includefallback to true. and the fallback list does
> indeed have stuff in it. But it's protected and I don't see how to get to
> it.
> 
> Can I expose the fallback table via a public get method?
> 
> 
> Is that a path that has any hope?
> 
> 
> 
> 
>  *So what's the most straight forward way to get to the list of libraries
> and modules within them?*
> 
> Thanks
> Miles
> 
> 
> 
> ___
> 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
> 




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] bug in numeric_evaluator?

[Jeff Young]

Yuck.  It’s clever code all right.  The “correct” version would be:

if( !ch || ( isDecSep( ch ) && sepCount ) )
   break;

but it’s a whole 3 characters longer. ;)

I’ll fix this in my 6.0 tree (which already has libeval re-formatted to Kicad 
standards), but I suggest we leave it sleeping for 5.0.

Cheers,
Jeff.


> On 13 Mar 2018, at 02:20, Jon Evans  wrote:
> 
> +Michael
> 
> This looks like "clever" code so I can't tell if this is a bug or not without 
> running through a bunch of test cases which I'm not going to do right now.
> Do you see any issues with the operation of the code, Mark, or just the 
> warning?
> 
> -Jon
> 
> On Mon, Mar 12, 2018 at 9:28 PM, Mark Roszko  > wrote:
> Not sure where to even begin looking at libeval since it looks scary but MSVC 
> complains:
> 
> D:\kicad-source-mirror\common\libeval\numeric_evaluator.cpp(216): warning 
> C4805: '==': unsafe mix of type 'char' and type 'bool' in operation
> 
> which is:
> 
>   auto ch = clToken.input[clToken.pos];
>   do {
>  if (ch == isDecSep(ch) && sepCount) break;
> 
> 
> ch is a char
> 
> isDecSep returns bool
> 
> char == bool?
> 
> 
> 
> -- 
> Mark
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> 
> Post to : kicad-developers@lists.launchpad.net 
> 
> Unsubscribe : https://launchpad.net/~kicad-developers 
> 
> More help   : https://help.launchpad.net/ListHelp 
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

[Kicad-developers] Making typed-in unit support more obvious

[Jeff Young]

There’s a wishlish item to make support for typed-in units more discoverable.

I think the easiest way to do this is to adopt a policy of removing unit 
static-texts following a value textCtrl in favour of displaying the current 
units in the text.

If the user clicks into the control and types only a number, we’ll assume 
current units and display them with the value when the textCtrl loses focus.

We already have all the code to support this.  I can clean up existing dialogs 
when I fix them for the eradication of g_UserUnit.

Thoughts?
___
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] Need guidance/hints on accessing list of available pcbnew footprints from python

[miles mccoo]

In one of my python plugins, I want to know the list of available
footprints (mounting holes, in this case)

Digging through the code, I can't make heads or tails of how to get this
information. There are a bunch of abstract class involved. impls

There are a couple possibilities, none of which seem clean.

*Stuff from FOOTPRINT plugin*
looking in footprint.i, I see some APIs that are close.
If I have a directory path to a fp library, I can
call pcbnew.FootprintEnumerate for a nice list.

but for that, I first have to have a list of fp library paths. *How do I
get such a list? *This seems like the closest answer. I see my config dir
has a fp-lib-table file which would be easy to parse. But that's a hack.



*FOOTPRINT_LIST_IMPL possibility*
looking in load_select_footprint, I see it has a static FOOTPRINT_LIST_IMPL
which does have the APIs I'd need to get to a nice list of footprint_infos.
But it's static to that file. I could copy the relevant code to
python_scripting_helpers. but that feels messy.

PCB_BASE_FRAME does have a method for popping up a table for a user to
choose a footprint, which is nice for UI. It could even be useful for
python plugins with some GUI stuff. But many python scripts will just want
a list of libraries and modules.



*PROJECT possibility*
I tried exposing PROJECT to python as it has a number of useful sounding
API including PcbFootprintLibs which returns a FP_LIB_TABLE. By poking
around in gdb, I see that FP_LIB_TABLE has GetCount and IsEmpty. IsEmpty
returns false if I set includefallback to true. and the fallback list does
indeed have stuff in it. But it's protected and I don't see how to get to
it.

Can I expose the fallback table via a public get method?


Is that a path that has any hope?




 *So what's the most straight forward way to get to the list of libraries
and modules within them?*

Thanks
Miles
___
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] Deletion in plugins causing trouble

[Maciej Sumiński]

Thank you Miles, I have just pushed your patch. I agree with Wayne, one
day we will need to revise the Python scripting interface.

Regards,
Orson

On 03/06/2018 10:02 AM, miles mccoo wrote:
> Thanks all for your replies.
> 
> I like the plugin mechanism. It does some nice things for python folks.
> Refresh, undo, garbage collection (I think). I want to see it succeed.
> 
> From reading Orson's mail, I think I wasn't entirely clear, so let me try
> to fix that first.
> 
> 
> The plugin mechanism tries to track the changes of a python plugin. In the
> c++ world, developers are expected to inform BOARD_COMMIT that something
> has changed. The plugin infrastructure does this for you. One could compare
> it to garbage collection. My interpretation of how this is done is simple:
> before a plugin runs, make a list of all design objects. zones, tracks,
> modules, nets... after the plugin completes, do a "diff".
> 
> This is mostly fine with the exception of removed items.
> 
> The problem with removed items is how do you do a diff on a deleted, memory
> managed, cleaned up object? Perhaps that memory now contains a different
> kind of object. Perhaps it's been reallocated to a similar object as before.
> 
> 
> 
> *as it stands now, any plugin that removes items from a board item
> container will likely fail*. It's not quite a crash, but it has a similar
> feel to the user.
> 
> 
> 
> Solutions. I can think of four.
> 
> solution 1. Why is the plugin mechanism in the business of tracking
> changes? Shouldn't BOARD_COMMIT just magically happen whenever a c++
> instance is modified. I brought this up in a previous thread[1] and various
> reasons were given why this isn't desirable.
> 
> solution 2. Same as #1 except BC magic only happens on python API calls.
> The plugin mechanism would no longer do diffs. Just add BC checkpoints.
> This is probably a lot of work. I might be willing to do this work but it
> would take time. [2]
> 
> solution 3. easy to implement. turn off deletion on calls to remove if
> currently running a plugin
> 
>- plugin gets a boolean: isPluginActive. set/unset around the call to
>actual python run code.
>- add pcbnew.isPluginActive() to python api. (I could imagine this could
>have other uses)
>- the remove code looks at isPluginActive to decide whether to set
>isown. (that code is actually python, not swig)
> 
> I have #3 implemented and my plugins no longer crash. *See attached patch
> for if folks agree it is an acceptable stopgap.*
> 
> solution 4. probably not the direction I would go but a way to enable
> python memory management and do the plugin diff thing. Basically, give each
> object some sort of unique id. (could be useful for other things). In
> addition to holding a list of object pointers, plugin infrastructure would
> hold a list of object ids.
> 
> 
> *Given the ease with which a plugin can hit this issue and given how long
> it would take to get #2 right, I guess I'm recommending the changes of that
> attached patch for #3.*
> 
> Miles
> 
> [1] https://lists.launchpad.net/kicad-developers/msg32063.html
> [2] I think my personal opinion is that #1 is superior over #2. Python
> people shouldn't have to care but why is it that c++ should or want to?
> Yes, I read the arguments from the previous thread but I'm not convinced.
> I'm also just a kicad spectator, so there's a lot I don't know.
> 
> 
> 
> 
> 
> On Fri, Mar 2, 2018 at 2:47 PM, Wayne Stambaugh 
> wrote:
> 
>> LOL, I just replied to Miles.  Thanks Orson for helping out!
>>
>> On 3/2/2018 8:36 AM, Maciej Sumiński wrote:
>>> Hi Miles,
>>>
>>> I suppose the silence in the thread indicates there are not many
>>> developers knowing the Python scripting interface inside out. Since you
>>> are both studying the scripting interface and developing own scripts, it
>>> is quite possible you are the most competent person to give us an advice
>>> on how to proceed. See some comments below, but I am neither a Python
>>> script developer nor a scripting interface maintainer, so I might be
>>> lacking some basic knowledge here.
>>>
>>> On 02/28/2018 05:12 PM, miles mccoo wrote:
 So I'm plugin-ifying my python scripts (the mechanism is awesome). One
>> of
 the plugins deletes some stuff and that is causing trouble.



 I'm not sure how to fix the root cause. Hence this mail.



 The plugin just deletes Edge.Cuts[1]:
 for d in board.GetDrawings():
 if (d.GetLayerName() == 'Edge.Cuts'):
 board.Remove(d)



 in board_item_container.i, I see this (with stuff deleted):
 %rename(RemoveNative)BOARD_ITEM_CONTAINER::Remove;
 def Remove(self,item):
 self.RemoveNative(item)
 item.thisown=1


 Setting thisown tells, python "you own it". Delete it when you're done.
 Which it does.


 The problem this causes is that the plugin mechanism