Re: [Kicad-developers] DRC changes

[Jeff Young]

Hi Ian,

Yeah, I tried just pushing the branch first, but it does the same thing.  I 
think I need to either delete all the other branches by hand, or turn off the 
“mirror” property (as that might force pushing of all branches).

Cheers,
Jeff.


> On 26 Apr 2020, at 15:21, Ian McInerney  wrote:
> 
> Try pushing only the branch you are actively working on to your personal repo.
> 
> In my setup, I have 2 remotes:
> 1) product - this is the main KiCad repo
> 2) personal - this is my personal fork
> 
> When I am working on a feature branch (called im/featurebranch) I push it to 
> my personal repo like this:
> `git push personal im/featurebranch`
> 
> Every other time I am working directly on master (such as for bug fixes or 
> smaller changes), I just push like this:
> `git push product master`
> 
> What is probably happening is that your fork has the main branches marked as 
> protected still - since they are marked as protected in the main repo the 
> fork copies that setting over.
> 
> -Ian
> 
> On Sun, Apr 26, 2020 at 3:14 PM Jeff Young  <mailto:j...@rokeby.ie>> wrote:
> So I set jeffyoung/kicad as a remote named “public” and set as a mirror.  But 
> when I push to it I get a bunch of errors:
> 
> Jeffs-MBP:kicad jeff$ git push public
> Enter passphrase for key '/Users/jeff/.ssh/id_rsa': 
> Enumerating objects: 3601, done.
> Counting objects: 100% (2535/2535), done.
> Delta compression using up to 8 threads
> Compressing objects: 100% (471/471), done.
> Writing objects: 100% (937/937), 529.58 KiB | 8.83 MiB/s, done.
> Total 937 (delta 797), reused 533 (delta 458)
> remote: Resolving deltas: 100% (797/797), completed with 378 local objects.
> remote: GitLab: You are not allowed to force push code to a protected branch 
> on this project.
> To gitlab.com <http://gitlab.com/>:jeffyoung/kicad.git
>  ! [remote rejected] 4.0 (pre-receive hook declined)
>  ! [remote rejected] 5.0 -> 5.0 (pre-receive hook declined)
>  ! [remote rejected] 5.1 -> 5.1 (pre-receive hook declined)
>  ! [remote rejected] drc (pre-receive hook declined)
> 
> This is all greek to me.  Any ideas?
> 
> Thanks,
> Jeff.
> 
> 
>> On 26 Apr 2020, at 14:58, Jeff Young > <mailto:j...@rokeby.ie>> wrote:
>> 
>> Never mind.  That page explains how to do the later.
>> 
>> 
>>> On 26 Apr 2020, at 14:56, Jeff Young >> <mailto:j...@rokeby.ie>> wrote:
>>> 
>>> And then the merge request, is that from jeff/kicad:jeffDRC to 
>>> jeff/kicad:master, or is there some way to do a merge request from 
>>> jeff/kicad:jeffDRC to kicad/code/kicad:master?
>>> 
>>>> On 26 Apr 2020, at 14:50, Ian McInerney >>> <mailto:ian.s.mciner...@ieee.org>> wrote:
>>>> 
>>>> Jeff,
>>>> 
>>>> From the main repository page, simply click on "Fork" at the top of the 
>>>> page. Then you create it inside your Personal namespace. Once you do that, 
>>>> the fork can just become a new remote in your git repository.
>>>> 
>>>> https://docs.gitlab.com/ee/user/project/repository/forking_workflow.html#creating-a-fork
>>>>  
>>>> <https://docs.gitlab.com/ee/user/project/repository/forking_workflow.html#creating-a-fork>
>>>> 
>>>> -Ian
>>>> 
>>>> On Sun, Apr 26, 2020 at 2:48 PM Jeff Young >>> <mailto:j...@rokeby.ie>> wrote:
>>>> I don’t have a personal repo.  Is it (reasonably) obvious how to create 
>>>> one?
>>>> 
>>>> > On 26 Apr 2020, at 14:32, Wayne Stambaugh >>> > <mailto:stambau...@gmail.com>> wrote:
>>>> > 
>>>> > Hi Jeff,
>>>> > 
>>>> > Would you please move your working branch from the main repo to your
>>>> > personal repo and create a merge request?  This will make it much easier
>>>> > to test and avoid poluting the main repo with developers personal
>>>> > working branches.
>>>> > 
>>>> > Thanks,
>>>> > 
>>>> > Wayne
>>>> > 
>>>> > On 4/26/20 8:27 AM, Jeff Young wrote:
>>>> >> I have added code to many DRC errors which shows the minimum clearance,
>>>> >> its source, and the actual clearance.
>>>> >> 
>>>> >> The old DRC code was pretty heavily optimised around the idea of only
>>>> >> needing to know if the clearance was violated (and not by how much), so
>>>> >> a lot of it has been re-wr

Re: [Kicad-developers] DRC changes

[Jeff Young]

Hi JP,

Did they report the same number of errors?

Thanks,
Jeff.


> On 26 Apr 2020, at 15:03, jp charras  wrote:
> 
> Le 26/04/2020 à 14:27, Jeff Young a écrit :
>> I have added code to many DRC errors which shows the minimum clearance, its 
>> source, and the actual clearance.
>> 
>> The old DRC code was pretty heavily optimised around the idea of only 
>> needing to know if the clearance was violated (and not by how much), so a 
>> lot of it has been re-written.  For this reason the new code is currently in 
>> a branch (jeffDRC).
>> 
>> I’d appreciate some testing on it if anyone gets a chance.  (More on the DRC 
>> errors themselves than the new reporting.)
>> 
>> Cheers,
>> Jeff.
>> 
>> PS: feel free to report issues here in email, or in 
>> https://gitlab.com/kicad/code/kicad/-/issues/2313.
>> 
> 
> Hi Jeff,
> I just tested it.
> 
> The old DRC code was pretty heavily optimized around the idea of only needing 
> to know if the clearance was violated because the calculation time
> is *much* faster than calculating actual distances.
> I tested the calculation time on the same (a 16 layers large board) with both 
> DRC versions:
> To test tracks clearance:
> Current algo: 14 s.
> Your new algo: 4 m
> 
> This is really a blocking problem.
> 
> -- 
> 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] DRC changes

[Jeff Young]

So I set jeffyoung/kicad as a remote named “public” and set as a mirror.  But 
when I push to it I get a bunch of errors:

Jeffs-MBP:kicad jeff$ git push public
Enter passphrase for key '/Users/jeff/.ssh/id_rsa': 
Enumerating objects: 3601, done.
Counting objects: 100% (2535/2535), done.
Delta compression using up to 8 threads
Compressing objects: 100% (471/471), done.
Writing objects: 100% (937/937), 529.58 KiB | 8.83 MiB/s, done.
Total 937 (delta 797), reused 533 (delta 458)
remote: Resolving deltas: 100% (797/797), completed with 378 local objects.
remote: GitLab: You are not allowed to force push code to a protected branch on 
this project.
To gitlab.com:jeffyoung/kicad.git
 ! [remote rejected] 4.0 (pre-receive hook declined)
 ! [remote rejected] 5.0 -> 5.0 (pre-receive hook declined)
 ! [remote rejected] 5.1 -> 5.1 (pre-receive hook declined)
 ! [remote rejected] drc (pre-receive hook declined)

This is all greek to me.  Any ideas?

Thanks,
Jeff.


> On 26 Apr 2020, at 14:58, Jeff Young  wrote:
> 
> Never mind.  That page explains how to do the later.
> 
> 
>> On 26 Apr 2020, at 14:56, Jeff Young > <mailto:j...@rokeby.ie>> wrote:
>> 
>> And then the merge request, is that from jeff/kicad:jeffDRC to 
>> jeff/kicad:master, or is there some way to do a merge request from 
>> jeff/kicad:jeffDRC to kicad/code/kicad:master?
>> 
>>> On 26 Apr 2020, at 14:50, Ian McInerney >> <mailto:ian.s.mciner...@ieee.org>> wrote:
>>> 
>>> Jeff,
>>> 
>>> From the main repository page, simply click on "Fork" at the top of the 
>>> page. Then you create it inside your Personal namespace. Once you do that, 
>>> the fork can just become a new remote in your git repository.
>>> 
>>> https://docs.gitlab.com/ee/user/project/repository/forking_workflow.html#creating-a-fork
>>>  
>>> <https://docs.gitlab.com/ee/user/project/repository/forking_workflow.html#creating-a-fork>
>>> 
>>> -Ian
>>> 
>>> On Sun, Apr 26, 2020 at 2:48 PM Jeff Young >> <mailto:j...@rokeby.ie>> wrote:
>>> I don’t have a personal repo.  Is it (reasonably) obvious how to create one?
>>> 
>>> > On 26 Apr 2020, at 14:32, Wayne Stambaugh >> > <mailto:stambau...@gmail.com>> wrote:
>>> > 
>>> > Hi Jeff,
>>> > 
>>> > Would you please move your working branch from the main repo to your
>>> > personal repo and create a merge request?  This will make it much easier
>>> > to test and avoid poluting the main repo with developers personal
>>> > working branches.
>>> > 
>>> > Thanks,
>>> > 
>>> > Wayne
>>> > 
>>> > On 4/26/20 8:27 AM, Jeff Young wrote:
>>> >> I have added code to many DRC errors which shows the minimum clearance,
>>> >> its source, and the actual clearance.
>>> >> 
>>> >> The old DRC code was pretty heavily optimised around the idea of only
>>> >> needing to know if the clearance was violated (and not by how much), so
>>> >> a lot of it has been re-written.  For this reason the new code is
>>> >> currently in a branch (jeffDRC).
>>> >> 
>>> >> I’d appreciate some testing on it if anyone gets a chance.  (More on the
>>> >> DRC errors themselves than the new reporting.)
>>> >> 
>>> >> Cheers,
>>> >> Jeff.
>>> >> 
>>> >> PS: feel free to report issues here in email, or
>>> >> in https://gitlab.com/kicad/code/kicad/-/issues/2313 
>>> >> <https://gitlab.com/kicad/code/kicad/-/issues/2313>.
>>> >> 
>>> >> ___
>>> >> Mailing list: https://launchpad.net/~kicad-developers 
>>> >> <https://launchpad.net/~kicad-developers>
>>> >> Post to : kicad-developers@lists.launchpad.net 
>>> >> <mailto:kicad-developers@lists.launchpad.net>
>>> >> Unsubscribe : https://launchpad.net/~kicad-developers 
>>> >> <https://launchpad.net/~kicad-developers>
>>> >> More help   : https://help.launchpad.net/ListHelp 
>>> >> <https://help.launchpad.net/ListHelp>
>>> >> 
>>> > 
>>> > ___
>>> > Mailing list: https://launchpad.net/~kicad-developers 
>>> > <https://launchpad.net/~kicad-developers>
>>> > Post to : kicad-developers

Re: [Kicad-developers] DRC changes

[Jeff Young]

Never mind.  That page explains how to do the later.


> On 26 Apr 2020, at 14:56, Jeff Young  wrote:
> 
> And then the merge request, is that from jeff/kicad:jeffDRC to 
> jeff/kicad:master, or is there some way to do a merge request from 
> jeff/kicad:jeffDRC to kicad/code/kicad:master?
> 
>> On 26 Apr 2020, at 14:50, Ian McInerney > <mailto:ian.s.mciner...@ieee.org>> wrote:
>> 
>> Jeff,
>> 
>> From the main repository page, simply click on "Fork" at the top of the 
>> page. Then you create it inside your Personal namespace. Once you do that, 
>> the fork can just become a new remote in your git repository.
>> 
>> https://docs.gitlab.com/ee/user/project/repository/forking_workflow.html#creating-a-fork
>>  
>> <https://docs.gitlab.com/ee/user/project/repository/forking_workflow.html#creating-a-fork>
>> 
>> -Ian
>> 
>> On Sun, Apr 26, 2020 at 2:48 PM Jeff Young > <mailto:j...@rokeby.ie>> wrote:
>> I don’t have a personal repo.  Is it (reasonably) obvious how to create one?
>> 
>> > On 26 Apr 2020, at 14:32, Wayne Stambaugh > > <mailto:stambau...@gmail.com>> wrote:
>> > 
>> > Hi Jeff,
>> > 
>> > Would you please move your working branch from the main repo to your
>> > personal repo and create a merge request?  This will make it much easier
>> > to test and avoid poluting the main repo with developers personal
>> > working branches.
>> > 
>> > Thanks,
>> > 
>> > Wayne
>> > 
>> > On 4/26/20 8:27 AM, Jeff Young wrote:
>> >> I have added code to many DRC errors which shows the minimum clearance,
>> >> its source, and the actual clearance.
>> >> 
>> >> The old DRC code was pretty heavily optimised around the idea of only
>> >> needing to know if the clearance was violated (and not by how much), so
>> >> a lot of it has been re-written.  For this reason the new code is
>> >> currently in a branch (jeffDRC).
>> >> 
>> >> I’d appreciate some testing on it if anyone gets a chance.  (More on the
>> >> DRC errors themselves than the new reporting.)
>> >> 
>> >> Cheers,
>> >> Jeff.
>> >> 
>> >> PS: feel free to report issues here in email, or
>> >> in https://gitlab.com/kicad/code/kicad/-/issues/2313 
>> >> <https://gitlab.com/kicad/code/kicad/-/issues/2313>.
>> >> 
>> >> ___
>> >> Mailing list: https://launchpad.net/~kicad-developers 
>> >> <https://launchpad.net/~kicad-developers>
>> >> Post to : kicad-developers@lists.launchpad.net 
>> >> <mailto:kicad-developers@lists.launchpad.net>
>> >> Unsubscribe : https://launchpad.net/~kicad-developers 
>> >> <https://launchpad.net/~kicad-developers>
>> >> More help   : https://help.launchpad.net/ListHelp 
>> >> <https://help.launchpad.net/ListHelp>
>> >> 
>> > 
>> > ___
>> > Mailing list: https://launchpad.net/~kicad-developers 
>> > <https://launchpad.net/~kicad-developers>
>> > Post to : kicad-developers@lists.launchpad.net 
>> > <mailto:kicad-developers@lists.launchpad.net>
>> > Unsubscribe : https://launchpad.net/~kicad-developers 
>> > <https://launchpad.net/~kicad-developers>
>> > More help   : https://help.launchpad.net/ListHelp 
>> > <https://help.launchpad.net/ListHelp>
>> 
>> 
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers 
>> <https://launchpad.net/~kicad-developers>
>> Post to : kicad-developers@lists.launchpad.net 
>> <mailto:kicad-developers@lists.launchpad.net>
>> Unsubscribe : https://launchpad.net/~kicad-developers 
>> <https://launchpad.net/~kicad-developers>
>> More help   : https://help.launchpad.net/ListHelp 
>> <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] DRC changes

[Jeff Young]

And then the merge request, is that from jeff/kicad:jeffDRC to 
jeff/kicad:master, or is there some way to do a merge request from 
jeff/kicad:jeffDRC to kicad/code/kicad:master?

> On 26 Apr 2020, at 14:50, Ian McInerney  wrote:
> 
> Jeff,
> 
> From the main repository page, simply click on "Fork" at the top of the page. 
> Then you create it inside your Personal namespace. Once you do that, the fork 
> can just become a new remote in your git repository.
> 
> https://docs.gitlab.com/ee/user/project/repository/forking_workflow.html#creating-a-fork
>  
> <https://docs.gitlab.com/ee/user/project/repository/forking_workflow.html#creating-a-fork>
> 
> -Ian
> 
> On Sun, Apr 26, 2020 at 2:48 PM Jeff Young  <mailto:j...@rokeby.ie>> wrote:
> I don’t have a personal repo.  Is it (reasonably) obvious how to create one?
> 
> > On 26 Apr 2020, at 14:32, Wayne Stambaugh  > <mailto:stambau...@gmail.com>> wrote:
> > 
> > Hi Jeff,
> > 
> > Would you please move your working branch from the main repo to your
> > personal repo and create a merge request?  This will make it much easier
> > to test and avoid poluting the main repo with developers personal
> > working branches.
> > 
> > Thanks,
> > 
> > Wayne
> > 
> > On 4/26/20 8:27 AM, Jeff Young wrote:
> >> I have added code to many DRC errors which shows the minimum clearance,
> >> its source, and the actual clearance.
> >> 
> >> The old DRC code was pretty heavily optimised around the idea of only
> >> needing to know if the clearance was violated (and not by how much), so
> >> a lot of it has been re-written.  For this reason the new code is
> >> currently in a branch (jeffDRC).
> >> 
> >> I’d appreciate some testing on it if anyone gets a chance.  (More on the
> >> DRC errors themselves than the new reporting.)
> >> 
> >> Cheers,
> >> Jeff.
> >> 
> >> PS: feel free to report issues here in email, or
> >> in https://gitlab.com/kicad/code/kicad/-/issues/2313 
> >> <https://gitlab.com/kicad/code/kicad/-/issues/2313>.
> >> 
> >> ___
> >> Mailing list: https://launchpad.net/~kicad-developers 
> >> <https://launchpad.net/~kicad-developers>
> >> Post to : kicad-developers@lists.launchpad.net 
> >> <mailto:kicad-developers@lists.launchpad.net>
> >> Unsubscribe : https://launchpad.net/~kicad-developers 
> >> <https://launchpad.net/~kicad-developers>
> >> More help   : https://help.launchpad.net/ListHelp 
> >> <https://help.launchpad.net/ListHelp>
> >> 
> > 
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers 
> > <https://launchpad.net/~kicad-developers>
> > Post to : kicad-developers@lists.launchpad.net 
> > <mailto:kicad-developers@lists.launchpad.net>
> > Unsubscribe : https://launchpad.net/~kicad-developers 
> > <https://launchpad.net/~kicad-developers>
> > More help   : https://help.launchpad.net/ListHelp 
> > <https://help.launchpad.net/ListHelp>
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> Post to : kicad-developers@lists.launchpad.net 
> <mailto:kicad-developers@lists.launchpad.net>
> Unsubscribe : https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> More help   : https://help.launchpad.net/ListHelp 
> <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] DRC changes

[Jeff Young]

Do I fork the project and put it in my “namespace”?

> On 26 Apr 2020, at 14:47, Jeff Young  wrote:
> 
> I don’t have a personal repo.  Is it (reasonably) obvious how to create one?
> 
>> On 26 Apr 2020, at 14:32, Wayne Stambaugh  wrote:
>> 
>> Hi Jeff,
>> 
>> Would you please move your working branch from the main repo to your
>> personal repo and create a merge request?  This will make it much easier
>> to test and avoid poluting the main repo with developers personal
>> working branches.
>> 
>> Thanks,
>> 
>> Wayne
>> 
>> On 4/26/20 8:27 AM, Jeff Young wrote:
>>> I have added code to many DRC errors which shows the minimum clearance,
>>> its source, and the actual clearance.
>>> 
>>> The old DRC code was pretty heavily optimised around the idea of only
>>> needing to know if the clearance was violated (and not by how much), so
>>> a lot of it has been re-written.  For this reason the new code is
>>> currently in a branch (jeffDRC).
>>> 
>>> I’d appreciate some testing on it if anyone gets a chance.  (More on the
>>> DRC errors themselves than the new reporting.)
>>> 
>>> Cheers,
>>> Jeff.
>>> 
>>> PS: feel free to report issues here in email, or
>>> in https://gitlab.com/kicad/code/kicad/-/issues/2313.
>>> 
>>> ___
>>> 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] DRC changes

[Jeff Young]

I don’t have a personal repo.  Is it (reasonably) obvious how to create one?

> On 26 Apr 2020, at 14:32, Wayne Stambaugh  wrote:
> 
> Hi Jeff,
> 
> Would you please move your working branch from the main repo to your
> personal repo and create a merge request?  This will make it much easier
> to test and avoid poluting the main repo with developers personal
> working branches.
> 
> Thanks,
> 
> Wayne
> 
> On 4/26/20 8:27 AM, Jeff Young wrote:
>> I have added code to many DRC errors which shows the minimum clearance,
>> its source, and the actual clearance.
>> 
>> The old DRC code was pretty heavily optimised around the idea of only
>> needing to know if the clearance was violated (and not by how much), so
>> a lot of it has been re-written.  For this reason the new code is
>> currently in a branch (jeffDRC).
>> 
>> I’d appreciate some testing on it if anyone gets a chance.  (More on the
>> DRC errors themselves than the new reporting.)
>> 
>> Cheers,
>> Jeff.
>> 
>> PS: feel free to report issues here in email, or
>> in https://gitlab.com/kicad/code/kicad/-/issues/2313.
>> 
>> ___
>> 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] DRC changes

[Jeff Young]

I have added code to many DRC errors which shows the minimum clearance, its 
source, and the actual clearance.

The old DRC code was pretty heavily optimised around the idea of only needing 
to know if the clearance was violated (and not by how much), so a lot of it has 
been re-written.  For this reason the new code is currently in a branch 
(jeffDRC).

I’d appreciate some testing on it if anyone gets a chance.  (More on the DRC 
errors themselves than the new reporting.)

Cheers,
Jeff.

PS: feel free to report issues here in email, or in 
https://gitlab.com/kicad/code/kicad/-/issues/2313 
.___
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] What is a global variable, and why we don't need them.

[Jeff Young]

This is indeed my particular problem.

But copy/paste only recently started using the system clipboard, so that would 
have been an issue too.  I can’t remember if the fixes for that are in 5.1 or 
6.0….

> On 13 Apr 2020, at 04:23, Andy Peters  wrote:
> 
> 
> 
>> On Apr 12, 2020, at 6:50 AM, Brian  wrote:
>> 
>> Just out of curiosity, what’s an example use case for multiple projects open 
>> at once, that isn’t served by multiple instances of KiCAD?  I admit I 
>> haven’t run into many reasons to have more than one open at a time in my own 
>> usage other than occasionally referring to an old project as a reference for 
>> a new one.
> 
> For starters, you can’t have multiple instances of Kicad running on macOS.
> 
> -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

Re: [Kicad-developers] What is a global variable, and why we don't need them.

[Jeff Young]

Yeah, I can’t believe g_RootSheet hasn’t gotten us into more trouble.  I guess 
most of the issues I’ve seen to-date with the globals have been between edit 
frames, and since only SCH_EDIT_FRAME uses sheets we’ve been OK.  (That being 
said, the last one was SCH_EDIT_FRAME and PLOTTER getting in a fight over a 
single instance of default line width.)

Multiple projects open at once would be really nice, though….

Cheers,
Jeff.

> On 12 Apr 2020, at 01:38, Dick Hollenbeck  wrote:
> 
> My definition:
> 
> I like to abstract the definition a little more than some designers, and 
> include things
> like singletons because a singleton intends to limit the number of instances 
> to one.  I
> would think you still have a global variable if you wrapped it into a class 
> with a single
> static instance.  You still only have one global instance.  That to me is 
> still a global
> variable with a fancy accessor, and that might even be worse.
> 
> If you can instantiate multiple instances, and the pointers to those 
> instances are in
> client user objects or on the stack, then you are probably not using a global.
> 
> Think of the world as being the *one* globe that we live on.  We have a 
> global air supply,
> and it spans all countries.  It is global because we cannot instantiate 
> another instance
> of the world's air supply, not because of how we spell its name, or where it 
> exits.
> 
> 
> The purpose of the PROJECT class was to create a place to store project 
> specific objects,
> with full intention of supporting more than one open project at some point in 
> time.  You
> can see this vision laid out in kiway.h.  Not a KiCad day goes by when I 
> don't have
> multiple KiCad projects open at the same time.  Currently, I typically am 
> working on one
> project under the project manager, but then load eeschema or pcbnew in 
> singletop mode to
> "view only" the other project data.
> 
> And even if multiple projects is not currently on the todo list, I think it 
> is a mistake
> to put road blocks in the path of supporting multiple projects at the same 
> time.  It is
> trivial to avoid those road blocks in most cases: avoid globals, including 
> singletons
> where one instance would not satisfy all projects. Instead, just use PROJECT 
> and stuff
> your PROJECT specific stuff into a PROJECT::_ELEM.
> 
> I recently got rid of g_RootSheet by using PROJECT.  It evolved through a can 
> of worms,
> but the worms are now all dead.  And the result is better than the formerly 
> closed can of
> worms.
> 
> One of the coolest features of PROJECT is the "data on demand" paradigm, or 
> some might
> call it lazy loading.  For python clients and what not, and any type of 
> window client of
> the PROJECT, it leaves the loading code out of sight and in a common place.
> 
> The main danger is the use of the virtual destructors in PROJECT::_ELEM.  
> That takes some
> getting used to.  You must destroy any PROJECT elements that you own before 
> your DSO gets
> kicked out of process. This means as you exit EESCHEMA, that DSO might get 
> unloaded from
> ram, particularly if all windows in eeschema are closed.  I don't know that 
> this unloading
> happens, but because it could happen, it is best to design for it.  And 
> mostly that means
> calling
>  SetElem( ELEMTYPE, nullptr );
> 
> in your clients' last destructor.
> 
> 
> 
> 
> 
> ___
> 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] Removal of some globals

[Jeff Young]

I had to remove some globals from Eeschema that were causing problems (default 
line width, text size, wire thickness, bus thickness etc.).

It was a large change (as these things always are), so let me know if you see 
anything odd.

Cheers,
Jeff.
___
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] component or symbol?

[Jeff Young]

Hi Marco,

In the netlist, no, because the elements it refers to are called “component” in 
the netlist file.

But everywhere else, yes.

Cheers,
Jeff.

> On 5 Apr 2020, at 11:02, Marco Ciampa  wrote:
> 
> 
> #: pcbnew/dialogs/dialog_netlist.cpp:279
> msgid "Using reference designators to match components and footprints.\n"
> 
> #: pcbnew/dialogs/dialog_netlist_base.cpp:43
> msgid "Link footprints using component tstamps (unique ids)"
> 
> Shouldn't the term symbol be used instead of component?
> 
> -- 
> 
> Saluton,
> Marco Ciampa
> 
> ___
> 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] Inconsistency within l10n strings

[Jeff Young]

Single quotes are much easier to read in the code (because they don’t require 
escaping).

But, yeah, it would be nice to standardise on a single approach.

Cheers,
Jeff.


> On 4 Apr 2020, at 19:10, Carsten Schoenert  wrote:
> 
> Hello Marco
> 
> Am 04.04.20 um 20:05 schrieb Marco Ciampa:
>> I do not know but perhaps rules are different in different countries?
> 
> that's for sure.
> 
>> For example single ' quote mark is never used in Italian so I always
>> convert them into a double " quote.
> 
> I mostly do so too, but every time the original string is changed I need
> to review this again. But the English source itself should be consistent
> on this to lower down the work on currently 5.722! strings. :-)
> 
> -- 
> 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


___
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] Saving the pin-to-pin map

[Jeff Young]

It’d certainly be better for situations where we’re saving lists, etc.  Is the 
JSON stuff all in so I could play around with that now, or do I need to wait a 
bit?

> On 12 Mar 2020, at 14:17, Jon Evans  wrote:
> 
> Or, maybe I didn't understand you right -- there are similar PARAM helpers 
> for JSON as well, so that code doesn't necessarily need to know about JSON 
> and its requirements/limitations in order to save settings.  I was not 
> planning on removing those and have everywhere that writes settings just 
> write to the JSON object directly.  If you think that would be better for 
> some situations, feel free to play around with that approach.
> 
> On Thu, Mar 12, 2020 at 10:15 AM Jon Evans  <mailto:j...@craftyjon.com>> wrote:
> Yes, that's right.  As part of splitting the project settings into different 
> files, those new files will be in JSON format, at which point all the 
> wxConfig helper code will be deprecated/removed.
> 
> On Thu, Mar 12, 2020 at 10:13 AM Jeff Young  <mailto:j...@rokeby.ie>> wrote:
> Hi Jon,
> 
> Speaking of which, I note that we’re still using the PARAM_CFG stuff to 
> read/write the stuff in the new preferences structs.  I assume that’s a 
> temporary measure and we’ll just be writing the structs to JSON at some point?
> 
> Thanks,
> Jeff.
> 
> 
>> On 12 Mar 2020, at 14:10, Jon Evans > <mailto:j...@craftyjon.com>> wrote:
>> 
>> Project (it will be moved into a separate ERC settings file)
>> 
>> On Thu, Mar 12, 2020 at 9:59 AM Jeff Young > <mailto:j...@rokeby.ie>> wrote:
>> We don’t currently save the ERC pin-to-pin map (which I would think makes it 
>> nearly useless).
>> 
>> Should it be project-relative, or global?
>> 
>> Cheers,
>> Jeff.
>> 
>> 
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers 
>> <https://launchpad.net/~kicad-developers>
>> Post to : kicad-developers@lists.launchpad.net 
>> <mailto:kicad-developers@lists.launchpad.net>
>> Unsubscribe : https://launchpad.net/~kicad-developers 
>> <https://launchpad.net/~kicad-developers>
>> More help   : https://help.launchpad.net/ListHelp 
>> <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] Saving the pin-to-pin map

[Jeff Young]

Hi Jon,

Speaking of which, I note that we’re still using the PARAM_CFG stuff to 
read/write the stuff in the new preferences structs.  I assume that’s a 
temporary measure and we’ll just be writing the structs to JSON at some point?

Thanks,
Jeff.


> On 12 Mar 2020, at 14:10, Jon Evans  wrote:
> 
> Project (it will be moved into a separate ERC settings file)
> 
> On Thu, Mar 12, 2020 at 9:59 AM Jeff Young  <mailto:j...@rokeby.ie>> wrote:
> We don’t currently save the ERC pin-to-pin map (which I would think makes it 
> nearly useless).
> 
> Should it be project-relative, or global?
> 
> Cheers,
> Jeff.
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> Post to : kicad-developers@lists.launchpad.net 
> <mailto:kicad-developers@lists.launchpad.net>
> Unsubscribe : https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> More help   : https://help.launchpad.net/ListHelp 
> <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] Saving the pin-to-pin map

[Jeff Young]

We don’t currently save the ERC pin-to-pin map (which I would think makes it 
nearly useless).

Should it be project-relative, or global?

Cheers,
Jeff.


___
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] Stroke font changes

[Jeff Young]

I brought the time to open Eeschema for the first time from ~ 5 seconds to 1 by 
changing the stroke font from a 3-dimensional vector (character x stroke x 
points) to 3 vectors (the top two of pointers and the bottom of wxPoints).

If you see anything fishy, it’s probably due to 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

Re: [Kicad-developers] DRC marker persistence

[Jeff Young]

Current implementation:

1) persists only the exclusions
2) persists them in the project file as a { error_code, main_item_desc, 
main_item_uuid, aux_item_desc, aux_item_uuid } tuple

We can easily break them out if the project file is migrated to multiple JSON 
files for 6.0.

Should have something for people to play with tomorrow.

Cheers,
Jeff.


> On 3 Mar 2020, at 21:01, Wayne Stambaugh  wrote:
> 
> On 3/3/20 3:59 PM, Jon Evans wrote:
>> Are you talking about temporary churn to project files?
>> In my opinion, I think during the 6.0 development cycle it's okay as
>> long as we stabilize by the time we cut a RC.
> 
> Churn.  But given that it only effects nightly builds, I can live with it.
> 
>> 
>> Again, in my opinion we should only persist the "ignore" rules, not
>> every marker, and if we take that approach, people won't be impacted
>> unless they use the ignore feature.
> 
> This is going to end up in the project file isn't it?  If so, then I
> have no issues with this.
> 
>> 
>> -Jon
>> 
>> On Tue, Mar 3, 2020 at 3:56 PM Wayne Stambaugh > <mailto:stambau...@gmail.com>
>> <mailto:stambau...@gmail.com <mailto:stambau...@gmail.com>>> wrote:
>> 
>>On 3/3/20 8:59 AM, Jon Evans wrote:
>>> Hi Jeff,
>>> 
>>> There are several ways to do persistence.  It sounds like you are
>>> planning to implement it as "save the state of all DRC markers", which
>>> is one way.
>>> Another way would be to just save the exceptions (aka waived
>>> violations), so closing and opening a board would not return the
>>markers
>>> to view, but re-running DRC would.
>>> 
>>> The choice of approach maybe impacts your questions.  If the goal
>>is to
>>> persist the entire state (i.e. someone can close and re-open
>>PcbNew and
>>> nothing is changed about the DRC markers), you obviously have to
>>save a
>>> lot more data and so the diff churn becomes more of a concern.  If you
>>> only persist the "settings" in the form of waived violations, there
>>> shouldn't really be a churn problem.
>>> 
>>> For ERC, I was always thinking that waived violations would have to be
>>> stored in a project-local settings file rather than any one schematic
>>> file, because ERC violations are not tied to a specific sheet.  It
>>seems
>>> fine to me to have this be a difference between ERC and DRC, though.
>>> 
>>> I personally do not think that I need the entire DRC state persisted
>>> across runs for my workflow.  I just need DRC to produce the same
>>> results every time it's run, and that includes persisting violations
>>> that I want ignored.
>>> In regards to what ignoring means, the first option seems
>>sufficient to
>>> me.  I'll have to check some commercial tools to see if they actually
>>> store more data, but I suspect not.
>>> Usually when I mark DRC violations as ignored (in Altium, for
>>example),
>>> it's because I know there is a specific situation going on with a
>>> certain item that is easier to ignore than to write a new rule
>>against.
>>> I don't use ignoring as a way of "bookmarking" where I am in a
>>long list
>>> of errors -- for that I just use clearing by type or by
>>> multi-selection.  Clearing (unlike ignoring) is not persisted in
>>Altium.
>>> 
>>> @Wayne - If we do decide to put them in project storage rather
>>than the
>>> board file, I'll be moving them out of the project file to a dedicated
>>> file along with everything else.  I'm fine with Jeff temporarily
>>adding
>>> stuff to the project file so as to not block him on the project
>>settings
>>> work I'm doing.
>> 
>>I'm just wondering about the impact to CVS users of adding them to the
>>project file.  I'm not sure if it's an issue or not.
>> 
>>> 
>>> -Jon
>>> 
>>> On Tue, Mar 3, 2020 at 8:42 AM Jeff Young >> <mailto:j...@rokeby.ie>
>><mailto:j...@rokeby.ie <mailto:j...@rokeby.ie>>
>>> <mailto:j...@rokeby.ie <mailto:j...@rokeby.ie> <mailto:j...@rokeby.ie 
>>> <mailto:j...@rokeby.ie>>>> wrote:
>>> 
>>>  Hi Henrik,
>>> 
>>>>  On 3 Mar 2020, at 13:33, Henrik Hansen
>>mailto:henrik.engga...@gmail.com> 
>> <mailto:henrik.engga...@gmail.com <mailto:henrik.engga...@gmail.com>>
>&

Re: [Kicad-developers] DRC marker persistence

[Jeff Young]

The current implementation has checkboxes below the list: [  ] All, [  ] 
Errors, [  ] Warnings, [  ] Exclusions.

If you check Exclusions you’ll see them in the main list, but greyed out.  
(Strikethrough would have been better, but alas there’s wxWidgets in the way 
again.)

> On 3 Mar 2020, at 15:22, Jon Evans  wrote:
> 
> My original UX proposal was to have them in an "ignored" group at the bottom 
> of the list, collapsed by default but still visible so that things can be 
> "unignored" without too much trouble.
> 
> On Tue, Mar 3, 2020 at 10:20 AM Nhat Khai  > wrote:
> Instead of persisted:
> 1) Can it has a expiration day, and user can reset/set or delete if needed ?
> 2) Or can user can still see them in the DRC list in a ignored group so they 
> can never be hidden completely from user?
> -Khai

___
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] DRC marker persistence

[Jeff Young]

Hi Henrik,

> On 3 Mar 2020, at 13:33, Henrik Hansen  wrote:
> 
> 1) As long as files with markers can be easily shared between people it is 
> good.
> 
> Why isn't "bloated diff" a problem for storing the markers in the project 
> files?

I don’t think people diff their project files, but I know some of them diff 
their board files.

> 
> Would it make sense to have an option to not store the markers?

That’s another option.

> 
> 2) The second scenario of marking a specific error is the least surprising. 
> How frequently will there be multiple errors of a certain type between the 
> two same objects? That is a risky scenario, but it is hard to asses without 
> knowing the chance.

It’s not for multiple errors, but for running DRC again.  So if I mark “ignore 
pad to pad clearance between pads 1 and 7 of U22”, when I run DRC again it will 
still ignore it.  (The risk is that I might have moved them even closer 
together, and that while the first clearance violation was deemed acceptable, 
the second wouldn’t be.  Then again, if you want to check again you can delete 
your ignore list.)

Cheers,
Jeff.


> 
> Best regards,
> Henrik
> 
> On Tue, Mar 3, 2020 at 11:04 AM Jeff Young  <mailto:j...@rokeby.ie>> wrote:
> Part of the 6.0 DRC architecture is marker persistence.  This will allow you 
> to work your way through a large set of DRC violations, flagging those that 
> have already been checked as exceptions or some-such.
> 
> Two questions:
> 
> 1) Store markers in board file or project file?
> 
> Board file is much easier (in fact currently zero-cost as it’s implemented in 
> my tree), but it may cause heartache in “bloated diff” camp?  (Note that you 
> can always press Delete All Markers when you’re done with DRC, so you can 
> choose to not have them in the board file.)
> 
> 2) Should exceptions be of the form “ignore error type X between object Y and 
> object Z”, or “this specific error condition is a false-positive”?
> 
> The first is more like a C++ #pragma.  The second is arguably “safer”, but 
> requires storing hashes of the entire data-state of objects Y and Z.  Likely 
> expensive to calculate on large boards (and somewhat expensive to implement).
> 
> Cheers,
> Jeff.
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> Post to : kicad-developers@lists.launchpad.net 
> <mailto:kicad-developers@lists.launchpad.net>
> Unsubscribe : https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> More help   : https://help.launchpad.net/ListHelp 
> <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] DRC marker persistence

[Jeff Young]

Part of the 6.0 DRC architecture is marker persistence.  This will allow you to 
work your way through a large set of DRC violations, flagging those that have 
already been checked as exceptions or some-such.

Two questions:

1) Store markers in board file or project file?

Board file is much easier (in fact currently zero-cost as it’s implemented in 
my tree), but it may cause heartache in “bloated diff” camp?  (Note that you 
can always press Delete All Markers when you’re done with DRC, so you can 
choose to not have them in the board file.)

2) Should exceptions be of the form “ignore error type X between object Y and 
object Z”, or “this specific error condition is a false-positive”?

The first is more like a C++ #pragma.  The second is arguably “safer”, but 
requires storing hashes of the entire data-state of objects Y and Z.  Likely 
expensive to calculate on large boards (and somewhat expensive to implement).

Cheers,
Jeff.
___
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] DRC reports

[Jeff Young]

At present Preferences holds only app-wide settings.  So if we went in this 
direction we’d want to do it en-masse.

> On 28 Feb 2020, at 14:48, Jon Evans  wrote:
> 
> I did mean Preferences but Board Setup would work as well.
> I haven't thought about this *too* hard but (and this is kind of a tangent 
> from the original topic) I think it might be better to think about 
> consolidating as many preferences as possible (whether they are global or 
> project-specific) into subpanes of the Preferences panel.
> 
> My thinking here:
> 
> 1) One-stop-shop means it's easier to remember what dialog to open
> 2) We could make the dialog searchable/filterable as is common in commercial 
> CAD/software dev tools with many preferences
> 3) Seeing all things in one location can remind you what settings you may 
> want to modify for a new project
> 4) I think we should implement more nice UI/UX around (a) storing default 
> settings for all new projects, and (b) importing certain types of settings 
> from other projects.  As this should apply across multiple types of settings 
> (not just DRC), it seemed to me that it would be easier to have a consistent 
> UX if everything is inside the Preferences dialog.
> 
> To expand on (4) for a bit, I had a vision of an "Import Settings" pane in 
> Preferences where you could pick a path to a different project.
> We could read that project, see what kind of settings are stored in it, then 
> present a list of checkboxes of things for the user to import:
> 
> [x] Board setup
> [x] DRC settings
> [x] Visibility and net color settings
> [x] Other project-specific settings
> [x] and so on
> 
> But, like I said, this is somewhat of a tangent from the specific matter of 
> DRC settings -- they could always live in the Board Setup for now, and move 
> later if we decide to go in the direction I describe.
> I do think that there should be no settings in the control dialog (other than 
> controlling reporting), but where they *do* live I don't feel as strongly 
> about :-)
> 
> -Jon
> 
> On Fri, Feb 28, 2020 at 6:27 AM Jeff Young  <mailto:j...@rokeby.ie>> wrote:
> Oops, probably didn’t read your email carefully enough.  You also mentioned 
> project-level, so I assume you also mean Board Setup, not Preferences.
> 
>> On 28 Feb 2020, at 11:26, Jeff Young > <mailto:j...@rokeby.ie>> wrote:
>> 
>> I was thinking Board Settings.  Some of them might be project-specific, no?
>> 
>>> On 28 Feb 2020, at 02:34, Jon Evans >> <mailto:j...@craftyjon.com>> wrote:
>>> 
>>> I agree settings should be in a different dialog.  I kind of think they 
>>> should go in the main preferences window as another entry (there will be 
>>> multiple "project level" preferences panes, so DRC/ERC setup could be part 
>>> of that).
>>> That taxonomy of reporting level sounds good to me.
>>> 
>>> I put my thoughts on taxonomy in a doc here for comment:
>>> https://docs.google.com/document/d/1r6tveX475pcCU-Gmv1rKIWM4i8ATsQVoWgNTytc0Ctw/edit#
>>>  
>>> <https://docs.google.com/document/d/1r6tveX475pcCU-Gmv1rKIWM4i8ATsQVoWgNTytc0Ctw/edit#>
>>> 
>>> -Jon
>>> 
>>> On Wed, Feb 26, 2020 at 6:22 AM Jeff Young >> <mailto:j...@rokeby.ie>> wrote:
>>> OK, I’m coming around to the idea of a hybrid system (tabs + outline + 
>>> severity filtering).
>>> 
>>> Jon, could you post your violation taxonomy here?
>>> 
>>> On the settings front, I do actually think they belong in a different 
>>> dialog (a la Allegro).  But we could have a right-button menu though that 
>>> takes you from an error to the preferences panel.  
>>> 
>>> The taxonomy I’d propose for the setting would be:
>>> - error
>>> - warning
>>> - info
>>> - ignore
>>> 
>>> The first 3 allow filtering; the last one is Allegro’s “off”.
>>> 
>>> 
>>>> On 26 Feb 2020, at 00:34, Evan Shultz >>> <mailto:evan.shu...@gmail.com>> wrote:
>>>> 
>>>> A few thoughts from the peanut gallery...
>>>> 
>>>> I strongly agree with Jon here, as a power user of Allegro's Constraint 
>>>> Manager. It simply _is_ complicated to navigate a full-featured design 
>>>> rule system. There will (may?) not be a way of getting around that when a 
>>>> lot of constraints have been added. Adding loads of tabs spreads things 
>>>> out which hurts users who are really using the design rule system. It can 
>>>> be overbearing at first, and

Re: [Kicad-developers] DRC reports

[Jeff Young]

Oops, probably didn’t read your email carefully enough.  You also mentioned 
project-level, so I assume you also mean Board Setup, not Preferences.

> On 28 Feb 2020, at 11:26, Jeff Young  wrote:
> 
> I was thinking Board Settings.  Some of them might be project-specific, no?
> 
>> On 28 Feb 2020, at 02:34, Jon Evans > <mailto:j...@craftyjon.com>> wrote:
>> 
>> I agree settings should be in a different dialog.  I kind of think they 
>> should go in the main preferences window as another entry (there will be 
>> multiple "project level" preferences panes, so DRC/ERC setup could be part 
>> of that).
>> That taxonomy of reporting level sounds good to me.
>> 
>> I put my thoughts on taxonomy in a doc here for comment:
>> https://docs.google.com/document/d/1r6tveX475pcCU-Gmv1rKIWM4i8ATsQVoWgNTytc0Ctw/edit#
>>  
>> <https://docs.google.com/document/d/1r6tveX475pcCU-Gmv1rKIWM4i8ATsQVoWgNTytc0Ctw/edit#>
>> 
>> -Jon
>> 
>> On Wed, Feb 26, 2020 at 6:22 AM Jeff Young > <mailto:j...@rokeby.ie>> wrote:
>> OK, I’m coming around to the idea of a hybrid system (tabs + outline + 
>> severity filtering).
>> 
>> Jon, could you post your violation taxonomy here?
>> 
>> On the settings front, I do actually think they belong in a different dialog 
>> (a la Allegro).  But we could have a right-button menu though that takes you 
>> from an error to the preferences panel.  
>> 
>> The taxonomy I’d propose for the setting would be:
>> - error
>> - warning
>> - info
>> - ignore
>> 
>> The first 3 allow filtering; the last one is Allegro’s “off”.
>> 
>> 
>>> On 26 Feb 2020, at 00:34, Evan Shultz >> <mailto:evan.shu...@gmail.com>> wrote:
>>> 
>>> A few thoughts from the peanut gallery...
>>> 
>>> I strongly agree with Jon here, as a power user of Allegro's Constraint 
>>> Manager. It simply _is_ complicated to navigate a full-featured design rule 
>>> system. There will (may?) not be a way of getting around that when a lot of 
>>> constraints have been added. Adding loads of tabs spreads things out which 
>>> hurts users who are really using the design rule system. It can be 
>>> overbearing at first, and making an easy on-ramp for novice users can be a 
>>> challenge, but I would hate to see a powerful design rules system that 
>>> doesn't work well for those who want to use it's capabilities. Allegro has 
>>> a dialog that turns each constraint on and off, which is totally separate 
>>> from setting up the values of each constraint. I personally think bringing 
>>> those two together would be helpful as they're tightly integrated.
>>> 
>>> If knowing how Allegro does it, simply to get another perspective but 
>>> certainly not as an example of the "correct way" to do something in an ECAD 
>>> tool is helpful, just let me know.
>>> 
>>> It could possibly be easier to manage if a simple graphic pops up for each 
>>> design rule showing a generic representation to what that constraint 
>>> pertains. Something like the Altium screenshot you showed above, Jon. Being 
>>> able to select a DRC marker and then get information about what's causing 
>>> it will help all users. Another helpful feature would be if two elements 
>>> could be selected and their constraints viewed, so that even if a DRC isn't 
>>> being generated the user can query the board. Lastly, some kind of report 
>>> would be useful to let a user search for net names and ref des and other 
>>> elements to see the design rules in the board, and if the report is 
>>> reasonably human-readable it might also suffice for an import/export design 
>>> rule file format.
>>> 
>>> One way of perhaps using tabs would be to break the pieces of the design 
>>> rule system down into different areas: electrical (trace lengths, diff 
>>> pairs, etc.), copper (allowable vias, trace widths, etc.), spacing, 
>>> silkscreen (silk over pads, min silk line width, courtyards, etc.). That 
>>> might allow a tab for each area with a tree system for the constraints 
>>> within each area. A spacing matrix is a powerful visualization tool which 
>>> could also fit into a tab.
>>> 
>>> One thing I haven't seen mentioned are the handling of groups of elements, 
>>> such as multiple traces which need their lengths matched or a net class 
>>> that contains multiple nets. How that is shown in the UI might require 
>>> another level since e

Re: [Kicad-developers] DRC reports

[Jeff Young]

I was thinking Board Settings.  Some of them might be project-specific, no?

> On 28 Feb 2020, at 02:34, Jon Evans  wrote:
> 
> I agree settings should be in a different dialog.  I kind of think they 
> should go in the main preferences window as another entry (there will be 
> multiple "project level" preferences panes, so DRC/ERC setup could be part of 
> that).
> That taxonomy of reporting level sounds good to me.
> 
> I put my thoughts on taxonomy in a doc here for comment:
> https://docs.google.com/document/d/1r6tveX475pcCU-Gmv1rKIWM4i8ATsQVoWgNTytc0Ctw/edit#
>  
> <https://docs.google.com/document/d/1r6tveX475pcCU-Gmv1rKIWM4i8ATsQVoWgNTytc0Ctw/edit#>
> 
> -Jon
> 
> On Wed, Feb 26, 2020 at 6:22 AM Jeff Young  <mailto:j...@rokeby.ie>> wrote:
> OK, I’m coming around to the idea of a hybrid system (tabs + outline + 
> severity filtering).
> 
> Jon, could you post your violation taxonomy here?
> 
> On the settings front, I do actually think they belong in a different dialog 
> (a la Allegro).  But we could have a right-button menu though that takes you 
> from an error to the preferences panel.  
> 
> The taxonomy I’d propose for the setting would be:
> - error
> - warning
> - info
> - ignore
> 
> The first 3 allow filtering; the last one is Allegro’s “off”.
> 
> 
>> On 26 Feb 2020, at 00:34, Evan Shultz > <mailto:evan.shu...@gmail.com>> wrote:
>> 
>> A few thoughts from the peanut gallery...
>> 
>> I strongly agree with Jon here, as a power user of Allegro's Constraint 
>> Manager. It simply _is_ complicated to navigate a full-featured design rule 
>> system. There will (may?) not be a way of getting around that when a lot of 
>> constraints have been added. Adding loads of tabs spreads things out which 
>> hurts users who are really using the design rule system. It can be 
>> overbearing at first, and making an easy on-ramp for novice users can be a 
>> challenge, but I would hate to see a powerful design rules system that 
>> doesn't work well for those who want to use it's capabilities. Allegro has a 
>> dialog that turns each constraint on and off, which is totally separate from 
>> setting up the values of each constraint. I personally think bringing those 
>> two together would be helpful as they're tightly integrated.
>> 
>> If knowing how Allegro does it, simply to get another perspective but 
>> certainly not as an example of the "correct way" to do something in an ECAD 
>> tool is helpful, just let me know.
>> 
>> It could possibly be easier to manage if a simple graphic pops up for each 
>> design rule showing a generic representation to what that constraint 
>> pertains. Something like the Altium screenshot you showed above, Jon. Being 
>> able to select a DRC marker and then get information about what's causing it 
>> will help all users. Another helpful feature would be if two elements could 
>> be selected and their constraints viewed, so that even if a DRC isn't being 
>> generated the user can query the board. Lastly, some kind of report would be 
>> useful to let a user search for net names and ref des and other elements to 
>> see the design rules in the board, and if the report is reasonably 
>> human-readable it might also suffice for an import/export design rule file 
>> format.
>> 
>> One way of perhaps using tabs would be to break the pieces of the design 
>> rule system down into different areas: electrical (trace lengths, diff 
>> pairs, etc.), copper (allowable vias, trace widths, etc.), spacing, 
>> silkscreen (silk over pads, min silk line width, courtyards, etc.). That 
>> might allow a tab for each area with a tree system for the constraints 
>> within each area. A spacing matrix is a powerful visualization tool which 
>> could also fit into a tab.
>> 
>> One thing I haven't seen mentioned are the handling of groups of elements, 
>> such as multiple traces which need their lengths matched or a net class that 
>> contains multiple nets. How that is shown in the UI might require another 
>> level since each of those groups must break out the elements within it to 
>> help the user configure the groups and track down where a DRC is being 
>> generated.
>> 
>> On Tue, Feb 25, 2020 at 4:12 PM Eeli Kaikkonen > <mailto:eeli.kaikko...@gmail.com>> wrote:
>> 
>> 
>> On Wed, Feb 26, 2020 at 1:29 AM Jon Evans > <mailto:j...@craftyjon.com>> wrote:
>> 
>> The problem with tabs is that they can only expand so far before you have to 
>> start scrolling (and so some tabs are not visible)

Re: [Kicad-developers] DRC reports

[Jeff Young]

OK, I’m coming around to the idea of a hybrid system (tabs + outline + severity 
filtering).

Jon, could you post your violation taxonomy here?

On the settings front, I do actually think they belong in a different dialog (a 
la Allegro).  But we could have a right-button menu though that takes you from 
an error to the preferences panel.  

The taxonomy I’d propose for the setting would be:
- error
- warning
- info
- ignore

The first 3 allow filtering; the last one is Allegro’s “off”.


> On 26 Feb 2020, at 00:34, Evan Shultz  wrote:
> 
> A few thoughts from the peanut gallery...
> 
> I strongly agree with Jon here, as a power user of Allegro's Constraint 
> Manager. It simply _is_ complicated to navigate a full-featured design rule 
> system. There will (may?) not be a way of getting around that when a lot of 
> constraints have been added. Adding loads of tabs spreads things out which 
> hurts users who are really using the design rule system. It can be 
> overbearing at first, and making an easy on-ramp for novice users can be a 
> challenge, but I would hate to see a powerful design rules system that 
> doesn't work well for those who want to use it's capabilities. Allegro has a 
> dialog that turns each constraint on and off, which is totally separate from 
> setting up the values of each constraint. I personally think bringing those 
> two together would be helpful as they're tightly integrated.
> 
> If knowing how Allegro does it, simply to get another perspective but 
> certainly not as an example of the "correct way" to do something in an ECAD 
> tool is helpful, just let me know.
> 
> It could possibly be easier to manage if a simple graphic pops up for each 
> design rule showing a generic representation to what that constraint 
> pertains. Something like the Altium screenshot you showed above, Jon. Being 
> able to select a DRC marker and then get information about what's causing it 
> will help all users. Another helpful feature would be if two elements could 
> be selected and their constraints viewed, so that even if a DRC isn't being 
> generated the user can query the board. Lastly, some kind of report would be 
> useful to let a user search for net names and ref des and other elements to 
> see the design rules in the board, and if the report is reasonably 
> human-readable it might also suffice for an import/export design rule file 
> format.
> 
> One way of perhaps using tabs would be to break the pieces of the design rule 
> system down into different areas: electrical (trace lengths, diff pairs, 
> etc.), copper (allowable vias, trace widths, etc.), spacing, silkscreen (silk 
> over pads, min silk line width, courtyards, etc.). That might allow a tab for 
> each area with a tree system for the constraints within each area. A spacing 
> matrix is a powerful visualization tool which could also fit into a tab.
> 
> One thing I haven't seen mentioned are the handling of groups of elements, 
> such as multiple traces which need their lengths matched or a net class that 
> contains multiple nets. How that is shown in the UI might require another 
> level since each of those groups must break out the elements within it to 
> help the user configure the groups and track down where a DRC is being 
> generated.
> 
> On Tue, Feb 25, 2020 at 4:12 PM Eeli Kaikkonen  > wrote:
> 
> 
> On Wed, Feb 26, 2020 at 1:29 AM Jon Evans  > wrote:
> 
> The problem with tabs is that they can only expand so far before you have to 
> start scrolling (and so some tabs are not visible).
> 
> Yes, that's why I thought a combination of tabs and a tree (or grid as you 
> said) may be good. There's still free space for a tab or two. Indeed, post-v5 
> the footprint warnings have got their own. I have always thought that the 
> messages about non-continous edge cut don't belong with the rest, so I would 
> move them to their own tab.
> 
> Eeli Kaikkonen
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> 
> Post to : kicad-developers@lists.launchpad.net 
> 
> Unsubscribe : https://launchpad.net/~kicad-developers 
> 
> More help   : https://help.launchpad.net/ListHelp 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] wx asserts in macOS

[Jeff Young]

I’d be inclined to leave them on for nightlies.

That being said, the signal-to-noise ratio on the reports we get is pretty low, 
so I don’t feel strongly.


> On 26 Feb 2020, at 05:21, Adam Wolf  wrote:
> 
> Hi folks!
> 
> Right now, wx debug/asserts are turned on for macOS nightly builds,
> but disabled for release builds.
> 
> Do they add value in the nightly builds to other devs, or should I
> disable them altogether?  Do we like it when users complain about them
> so that we know where to fix things? :)
> 
> Adam
> 
> ___
> 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] DRC reports

[Jeff Young]

You’ve got me half-convinced on collapsing the tabs.  But there’s one last 
issue: running the footprints checks is much slower and so is turned off by 
default.  We partially mitigate that by displaying “not run” in the Footprints 
tab. I suppose we could put the warning as a single item under a Footprints 
section, but then you can’t hide it.

I’d still miss quickly checking at different levels.  But if we allowed setting 
an error/warning/info level for each error (or error class), then I could still 
quickly switch between errors and warnings.

At what point are we over-building this, though?

> On 25 Feb 2020, at 22:34, Jon Evans  wrote:
> 
> Coming from the point of view of using commercial tools, I don't really see 
> the three tabs as different categories.
> An unconnected is a violation: it violates the implicit rule that all net 
> items must be connected.  Generally, advanced tools allow you to override 
> this default rule.
> For example, Altium's default rule for unrouted nets:
> 
> You could change the filter so that there are some areas where unrouted nets 
> are allowed, if you wanted to do your design this way.
> 
> And, there are also clearance rules that fall in the category of "did you 
> mean ==" in that sometimes you actually know better than the checker (this is 
> especially true with the current state of what rules are possible to express 
> in KiCad, but will still be true even with a complex rules engine, in my 
> experience)
> 
> The way I had been thinking about it is that if there is a type of rule that 
> you just don't want to see, you would just disable that rule in the project 
> DRC settings.
> The tree would only ever show the hierarchy for violations that exist (i.e. 
> empty top level sections would be suppressed) so it would not be too 
> cluttered.
> 
> -Jon
> 
> On Tue, Feb 25, 2020 at 5:27 PM Jeff Young  <mailto:j...@rokeby.ie>> wrote:
> Now that it’s a tree we could do the 3 level hierarchy pretty easily.  In 
> fact, I started to, but I found it really annoying with my small boards where 
> I usually only have a handful of errors.  That’s when I had the filter 
> checkbox idea.
> 
> I also thought about collapsing the 3 tabs.  But they really are different: 
> an unconnected isn’t a violation (there’s no rule that it violates).  
> Similarly, the Footprint Warnings are more like C++’s “did you mean ==” 
> warning when you use a single “=” in an odd place: they as likely to be wrong 
> as right.
> 
> I do like the right-click clear and ignore actions.  And I think those are 
> fine to do at the 64-types granularity.  But I don’t really want to do that 
> just to not show courtyard violations.
> 
>> On 25 Feb 2020, at 20:53, Jon Evans > <mailto:j...@craftyjon.com>> wrote:
>> 
>> Some mockup to give context to my earlier reply:
>> You could right-click a given violation, and clear (one-time) or ignore 
>> (persistent) either that particular violation, or all violations of its 
>> class.
>> You could also right-click the class header ("Clearance Violations") and 
>> clear all / ignore all.
>> 
>> 
>> 
>> On Tue, Feb 25, 2020 at 3:21 PM Jon Evans > <mailto:j...@craftyjon.com>> wrote:
>> The idea I was kicking around was to build a 2-level tree, with the parents 
>> being these categories (in new drc branch):
>> https://gitlab.com/kicad/code/kicad/-/blob/drc/pcbnew/drc/drc_violation.h#L31
>>  
>> <https://gitlab.com/kicad/code/kicad/-/blob/drc/pcbnew/drc/drc_violation.h#L31>
>> I think there are much fewer than 64 error types that actually need to be 
>> displayed to the user in groups.  I'm not sure the enum there has absolutely 
>> everything, but I do think it's close.
>> 
>> I was planning on getting rid of the 3 tabs -- I don't think it makes sense 
>> to have the three tabs and also filters in the "violations" tab -- the other 
>> two tabs are just different types of violations.
>> 
>> I am also not sure how much it makes sense to have checkboxes for 
>> showing/hiding violations.
>> It seems like a better ultimate state would be:
>> (a) being able to turn on/off all types of violations (and set their 
>> severity)
>> (b) being able to clear or ignore certain violations or certain classes of 
>> violations in one go (I was thinking via a context menu on each violation 
>> and the tree header per violation class)
>> 
>> -Jon
>> 
>> On Tue, Feb 25, 2020 at 2:34 PM Jeff Young > <mailto:j...@rokeby.ie>> wrote:
>> I’m looking at adding filtering to the DRC window.  I’d like to use 
>> something similar to the HTML report panel wher

Re: [Kicad-developers] DRC reports

[Jeff Young]

Now that it’s a tree we could do the 3 level hierarchy pretty easily.  In fact, 
I started to, but I found it really annoying with my small boards where I 
usually only have a handful of errors.  That’s when I had the filter checkbox 
idea.

I also thought about collapsing the 3 tabs.  But they really are different: an 
unconnected isn’t a violation (there’s no rule that it violates).  Similarly, 
the Footprint Warnings are more like C++’s “did you mean ==” warning when you 
use a single “=” in an odd place: they as likely to be wrong as right.

I do like the right-click clear and ignore actions.  And I think those are fine 
to do at the 64-types granularity.  But I don’t really want to do that just to 
not show courtyard violations.

> On 25 Feb 2020, at 20:53, Jon Evans  wrote:
> 
> Some mockup to give context to my earlier reply:
> You could right-click a given violation, and clear (one-time) or ignore 
> (persistent) either that particular violation, or all violations of its class.
> You could also right-click the class header ("Clearance Violations") and 
> clear all / ignore all.
> 
> 
> 
> On Tue, Feb 25, 2020 at 3:21 PM Jon Evans  <mailto:j...@craftyjon.com>> wrote:
> The idea I was kicking around was to build a 2-level tree, with the parents 
> being these categories (in new drc branch):
> https://gitlab.com/kicad/code/kicad/-/blob/drc/pcbnew/drc/drc_violation.h#L31 
> <https://gitlab.com/kicad/code/kicad/-/blob/drc/pcbnew/drc/drc_violation.h#L31>
> I think there are much fewer than 64 error types that actually need to be 
> displayed to the user in groups.  I'm not sure the enum there has absolutely 
> everything, but I do think it's close.
> 
> I was planning on getting rid of the 3 tabs -- I don't think it makes sense 
> to have the three tabs and also filters in the "violations" tab -- the other 
> two tabs are just different types of violations.
> 
> I am also not sure how much it makes sense to have checkboxes for 
> showing/hiding violations.
> It seems like a better ultimate state would be:
> (a) being able to turn on/off all types of violations (and set their severity)
> (b) being able to clear or ignore certain violations or certain classes of 
> violations in one go (I was thinking via a context menu on each violation and 
> the tree header per violation class)
> 
> -Jon
> 
> On Tue, Feb 25, 2020 at 2:34 PM Jeff Young  <mailto:j...@rokeby.ie>> wrote:
> I’m looking at adding filtering to the DRC window.  I’d like to use something 
> similar to the HTML report panel where we’d have some checkboxes under the 
> listbox:
> 
> [ ] Show All   [ ] Clearances  [ ] Constraints   [ ] Courtyards
> 
> It would be nice and consistent to then have a Save button after that.  But 
> this would be a slight procedural change:
> 1) it would separate the reports by the 3 tabs: Violations, Unconnected, 
> Footprint Warnings
> 2) you couldn’t set it and forget it: you’d have to click the Save button 
> each time you wanted a report
> 
> Thoughts?
> 
> Note: yes, I did consider user-defined filtering.  But we currently have 64 
> DRC error types, and I’m not sure users really want to wade through that list 
> (nor do we want to have to reply to queries of the form “what does DRC error 
> type XYZ include?”
> 
> Note 2: regardless of that, feel free to comment on anything (including “we 
> really must have user-defined filtering”).
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> Post to : kicad-developers@lists.launchpad.net 
> <mailto:kicad-developers@lists.launchpad.net>
> Unsubscribe : https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> More help   : https://help.launchpad.net/ListHelp 
> <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] DRC reports

[Jeff Young]

I’m looking at adding filtering to the DRC window.  I’d like to use something 
similar to the HTML report panel where we’d have some checkboxes under the 
listbox:

[ ] Show All   [ ] Clearances  [ ] Constraints   [ ] Courtyards

It would be nice and consistent to then have a Save button after that.  But 
this would be a slight procedural change:
1) it would separate the reports by the 3 tabs: Violations, Unconnected, 
Footprint Warnings
2) you couldn’t set it and forget it: you’d have to click the Save button each 
time you wanted a report

Thoughts?

Note: yes, I did consider user-defined filtering.  But we currently have 64 DRC 
error types, and I’m not sure users really want to wade through that list (nor 
do we want to have to reply to queries of the form “what does DRC error type 
XYZ include?”

Note 2: regardless of that, feel free to comment on anything (including “we 
really must have user-defined filtering”).
___
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] Proposal to update eeSchema annotation?

[Jeff Young]

“Real” sheet numbering would be nice (ie: instead of page number times X, have 
a way to prefix by sheet start ref, and have a way to define that in the sheet).

> On 22 Feb 2020, at 14:47, Brian Piccioni  wrote:
> 
> Hello
> Now that Geographic Reannotation is a WIP I was thinking it might make sense 
> to update eeSchema's Annotate dialog.
> I propose the following:
> Change to dialog:
> Add to Scope: Selection
> Add to Numbering:Add/Remove prefixes (allows conformance to ASME Y14.44 
> and IEEE 315)
>   Replace "page number times 100, 1000" 
> with "page number times X" 
> Add optional push to PCB 
> Place Advanced options on a tab.
> General:
> Incorporate undo
> Perform a "sanity check" on new annotation to check for redundant references 
> before committing it.
> Other:
> Additional suggestions?
> 
> Compared to Geographic Reannotation this should be straightforward. I do not 
> see any need to modify PCBNew code.
> Also I have a better understanding of the code and process and should require 
> less hand holding.
> Any thoughts?
> Brian
> ___
> 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] What does /path do in PCBNew files?

[Jeff Young]

Pasting creates new timestamps.  So copy/paste works fine, there’s just no way 
to do a unified copy/paste between eeschema *and* pcbnew.

The timestamps are moving to UUIDs as we speak.

The links are reset/updated when you do an Update PCB from Schematic and chose 
the “re-associate by reference” option.  (The timestamps/UUIDs encode said 
“association”.)

Cheers,
Jeff.


> On 15 Feb 2020, at 23:40, Brian Piccioni  wrote:
> 
> I guess I'd wonder then why provide Copy and Paste/Duplicate if the result is 
> not usable?
> 
> It seems like a sort of honey pot.
> 
> On 2020-02-15 6:34 p.m., Eeli Kaikkonen wrote:
>> 
>> 
>> 
>> On Sun, Feb 16, 2020 at 1:20 AM Brian Piccioni > > wrote:
>> I think optionally removing the path might be a good idea - or, simply 
>> removing it from duplicated/pasted footprints. Of course I am probably 
>> missing something.
>> 
>> Brian
>> 
>> You can't backannotate something which doesn't have the "path". But those 
>> footprints can of course be re-annotated.
>> 
>> I don't think it's possible to cleanly copypaste groups of footprints to 
>> create "duplicated design elements" as you say. Either they point to one 
>> group of symbols while they should point to hierarchical sheet instances 
>> (each of which have different path), or they don't have corresponding 
>> symbols at all.
>> 
>> If you have two footprints with identical "paths" you can reannotate from 
>> eeshcema (with a warning IIRC) and both footprints will have the same 
>> refdes. But it doesn't make sense to have two footprints with different 
>> refdes to point to one symbol because the symbol has only one refdes.
>> 
>> Having identical paths in more than one footprints is problematic anyways. I 
>> have used it but I don't recommend it.
>> 
>> Eeli Kaikkonen
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] Broken Linux build

[Jeff Young]

Yes, I also see the issue (on OSX).

> On 7 Feb 2020, at 17:40, Jon Evans  wrote:
> 
> Wayne, can you revert the changes on lines 343-347 and add back -DDEBUG to 
> those four locations, keeping the added part around line 173 of the 
> CMakeLists.txt?
> 
> If that fixes it, it tells us that for some reason the set_property call is 
> not resulting in the -DDEBUG making it into the makefiles on your system.
> 
> (see: 
> https://gitlab.com/kicad/code/kicad/commit/b824051adf246c6d5d30a1a5806dd7a194f23700#9a2aa4db38d3115ed60da621e012c0efc0172aae_339_343
>  
> 
>  )
> 
> -Jon
> 
> On Fri, Feb 7, 2020 at 12:29 PM Jon Evans  > wrote:
> At the moment I only have access to my Mac, and can confirm that -DDEBUG does 
> get added to my build file although it doesn't show as a variable in 
> CMakeCache.txt
> 
> I use ninja so I see it in the build lines of the build.ninja file
> 
> Can you confirm if your makefile has -DDEBUG set or not for the compile 
> commands somewhere?
> 
> Does anyone else see this issue?
> 
> On Fri, Feb 7, 2020 at 12:26 PM Wayne Stambaugh  > wrote:
> Neither `make rebuild_cache` or a clean build fixed the issue.  Attached
> is the CMakeCache.txt file.
> 
> On 2/7/20 11:50 AM, Jon Evans wrote:
> > LIB_ID::Test is hidden behind a DEBUG ifdef check.  So, it seems like in
> > your configuration the CMake change is not setting DEBUG anymore.
> > Are you able to inspect your CMakeCache.txt to shed some light on this?
> > 
> > 
> > On Fri, Feb 7, 2020 at 11:46 AM Wayne Stambaugh  > 
> > >> wrote:
> > 
> > I'm running into this build failure on my Debian Bullseye box as of the
> > latest commits to the master branch:
> > 
> > /usr/bin/ld:
> > ../../pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/pcbnew_wrap.cxx.o: in
> > function `_wrap_LIB_ID_Test':
> > 
> > /home/wayne/build/kicad/trunk-debug-gtk3-python/pcbnew/pcbnew_wrap.cxx:53313:
> > undefined reference to `LIB_ID::Test()'
> > collect2: error: ld returned 1 exit status
> > make[2]: ***
> > [qa/pcbnew_tools/CMakeFiles/qa_pcbnew_tools.dir/build.make:686:
> > qa/pcbnew_tools/qa_pcbnew_tools] Error 1
> > make[1]: *** [CMakeFiles/Makefile2:4612:
> > qa/pcbnew_tools/CMakeFiles/qa_pcbnew_tools.dir/all] Error 2
> > make[1]: *** Waiting for unfinished jobs
> > /usr/bin/ld:
> > ../../pcbnew/CMakeFiles/pcbnew_kiface_objects.dir/pcbnew_wrap.cxx.o: in
> > function `_wrap_LIB_ID_Test':
> > 
> > /home/wayne/build/kicad/trunk-debug-gtk3-python/pcbnew/pcbnew_wrap.cxx:53313:
> > undefined reference to `LIB_ID::Test()'
> > collect2: error: ld returned 1 exit status
> > make[2]: *** [qa/pcbnew/CMakeFiles/qa_pcbnew.dir/build.make:792:
> > qa/pcbnew/qa_pcbnew] Error 1
> > make[1]: *** [CMakeFiles/Makefile2:4306:
> > qa/pcbnew/CMakeFiles/qa_pcbnew.dir/all] Error 2
> > make: *** [Makefile:163: all] Error 2
> > 
> > Git bisect blames commit b824051adf246c6d5d30a1a5806dd7a194f23700 as the
> > culprit.  If someone could fix this, I would appreciate at it.  I can
> > file an issue on GitLab if its helpful.
> > 
> > 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

___
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] What should I base my work on? 5.5 or 6?

[Jeff Young]

I’ve been using 6.0 for boards.  Just completed 5 of them.

I’m not even using git with them.  (But that’s because I’m an idiot.  I’m also 
currently in the middle of re-ripping 500 CDs because I didn’t back up my music 
server either.)

Cheers,
Jeff.


> On 5 Feb 2020, at 16:36, Seth Hillbrand  wrote:
> 
> On 2020-02-05 09:30, Brian wrote:
>> Hello friends,
>> I've talked about my ODBC back-end for symbol and footprint libraries
>> a few times.  I originally developed it on an early 5.something, and
>> parts of it got broken with the latest 5.x.  I haven't been doing a
>> lot of EDA work, so it hasn't been a priority to fix, but I'm gearing
>> up for some new designs and figured it's time to tackle it again.
>> So my question:  If I want a stable, reliably-usable KiCad environment
>> to do actual EDA work in, should I be basing my ODBC mods on the
>> latest 5.x or 6?  If I do base it on 5.x, will that be wasted effort
>> when 6 becomes more "stable"?
>> Also related, a while back there was some talk about developing an
>> actual dynamic-load plug-in system for KiCad.  I had indicated some
>> interest in contributing to that goal, but my own minor efforts
>> definitely died on the vine.  Has anything come of that?  Are there
>> any design documents folks have put together?
>> Cheers,
>> -Brian
> 
> Hi Brian-
> 
> All work should be based on v6.  No features will be added to v5.  v6 has 
> changed sufficiently that any work based on v5 will likely be lost when v6 is 
> released.
> 
> v6 is unstable.  That said, I produce regular boards using it and I know of a 
> few others who do the same.  If you do this, get into the habit of using git 
> to check in your work regularly.  This will limit the potential loss in the 
> event of bugs.
> 
> There is no dynamic loading system planned beyond what exists now.  There 
> will be a new Python-based plugin system in v6.
> 
> Seth Hillbrand
> KiCad Services Corporation
> https://www.kipro-pcb.com
> +1 530 302 5483 | +1 212 603 9372
> 
> ___
> 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] macos notarization status

[Jeff Young]

Awesome!  Great job, Adam.


> On 4 Feb 2020, at 22:03, Adam Wolf  wrote:
> 
> Hi folks!
> 
> Good news.
> 
> On my dev machine, I've got the DMG, the apps, all the frameworks,
> everything, all notarized.  The apps are all signed even!
> 
> We don't need to change the symlinks! (I'm a little bummed that the
> relayed question->answer from WWDC wasn't accurate, but that was 3
> years ago, and there have been changes to how notarization is enforced
> as recently as 2020/02/03. :) )
> 
> What was it?  A combination of two things:
> 
> * Moving some Python and ngspice things around in the bundle so that
> only certain types of executables were in certain directories of the
> bundle
> * Apple says to submit a zip to their notarization service.  If you
> create a zip with "zip", it won't work. You need to use ditto with a
> few different arguments.  I suspect that this was messing with the
> symlinks.  *sigh*
> 
> Alright, so what's next?
> 
> 1) I want to remove all the KiCad patches from kicad-mac-builder,
> long-term.  As part of that, there's a few changes from this effort
> that I want to get into the KiCad cmake files.  I think they're
> innocent and gentle but we can discuss them on the MRs I'll make. :)
> However, I have an old patch to create a distributable Python
> Framework that I don't really want to merge into our tree--and I am
> personally OK with leaving it as a patch in kicad-mac-builder, since
> a) it has been that way since I created it years ago and 2) my next
> effort after this notarization/signing is 100% done is getting Python
> 3 working on the macOS builds, and as part of that I'll be getting rid
> of this patch.  At that point kicad-mac-builder won't have any KiCad
> patches at all.
> 
> 2) It is certainly possible that I broke things or made minor mistakes
> with signing/notarization, so I will generate some of these builds on
> my dev machine and get them available as testing builds for people to
> test.
> 
> 3) It is possible there are ways that users use the apps now that will
> break.  For instance, it will no longer be OK for users to put their
> own files inside the bundle.  This is a good thing, but we may need to
> prepare some instructions or something to help break it to users--if
> anyone has strong opinions here please let me know.  I am terrified
> that users are doing this, downloading a new version of KiCad,
> overwriting their old "executables" and then losing their data files.
> I have read of at least one report of this happening on kicad.info and
> it breaks my heart.   I know there has been some confusion about this
> point technically but see
> https://developer.apple.com/library/archive/technotes/tn2206/_index.html#//apple_ref/doc/uid/DTS40007919-CH1-TNTAG304
> for details.
> 
> 4) I have some kicad-mac-builder changes to make to get all of this
> signing and notarization stuff working on CI.  I expect this will take
> at least a few days as the part I need to modify the most is a part
> that's been a pain lately and needs to be gutted anyway...
> 
> 5) When all of this is done, and this is stable, Python 3 on macOS is
> next on my plate.
> 
> Thanks folks!
> 
> If anyone has any questions or comments or opinions on this stuff, let
> me know, otherwise I'll keep at it :)
> 
> Adam Wolf
> 
> On Mon, Feb 3, 2020 at 10:05 AM Bernhard Stegmaier
>  wrote:
>> 
>> Adam,
>> 
>> One last thing, just to be sure… you are notarizing the final kicad.app 
>> after the “make install”?
>> If you use the (intermediate) one of the build directory, the sub-bundles 
>> might not yet be in place as they should…
>> 
>> 
>> Bernhard
>> 
>>> On 3. Feb 2020, at 16:59, Bernhard Stegmaier  
>>> wrote:
>>> 
>>> OK, I see… this is weird.
>>> My understanding from what I read in the documentation was, that it should 
>>> sign everything in the top-level bundle (kicad.app) including sub-apps you 
>>> might have in kicad.app/Contents/Applications.
>>> 
>>> 
>>> Regards,
>>> Bernhard
>>> 
 On 3. Feb 2020, at 16:47, Adam Wolf  wrote:
 
 I am not notarizing the DMGs.  While this is possible, it has not been
 necessary so far.
 
 When I tried notarizing kicad.app but not the others, when I move to a
 new computer, it complains that eeschema.app is not notarized.
 
 The problem is not putting the signed kicad.app into an unsigned dmg.
 
 On Mon, Feb 3, 2020 at 8:11 AM Bernhard Stegmaier
  wrote:
> 
> Hi Adam,
> 
> I am also no fan of the symlinks, but having a different approach will
> be probably some work.
> 
>> I had someone ask if what we do would work during WWDC and I was told
>> it would not work.  I consistently get "the signature is invalid" when
>> signing while we have symlinks, and when I remove the symlinks and
>> just sign KiCad.app this error goes away.
> 
> I don't doubt that the symlinks in the DMG don't work.
> What you explained is exactly what I had in mind:
> (1) Sign 

Re: [Kicad-developers] Welcome New Bug Squad members

[Jeff Young]

Welcome, guys!

> On 4 Feb 2020, at 14:15, Dino Ghilardi  wrote:
> 
> Congratulations Eeli and Simon!
> 
> Dino.
> 
> On 04/02/20 10:40, Seth Hillbrand wrote:
>> Welcome to our newest Bug Squad members Eeli Kaikkonen and Simon Richter.  
>> As members of the Bug Squad, they help to verify, triage and classify our 
>> bug reports, serving a critical role in ensuring KiCad continues to improve.
>> Thanks to you both along with long-time squad member Michael Kavanaugh for 
>> all that you do to push KiCad forward.  We look forward to building great 
>> things together.
>> Best-
>> Seth
>> Seth Hillbrand
>> KiCad Services Corporation
>> https://www.kipro-pcb.com
>> +1 530 302 5483 | +1 212 603 9372
>> ___
>> 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 source code]

[Jeff Young]

Hi Andrea,

Have a look at SCH_DRAWING_TOOLS::PlaceComponent().

Cheers,
Jeff.

> On 3 Feb 2020, at 18:08, Andrea Martí  wrote:
> 
> Hi, 
> I posted this question on the kicad forums website and someone directed me to 
> the developer's mailing list instead of that forum. I have been looking into 
> the source code in order to develop my own project and I have a question 
> regarding the Eeschema source code. 
> In particular, is there a specific file or function in the source code that 
> tells us how to place a symbol from the library to the schematic board?I 
> would like to be able to click a button and have the component appear, akin 
> to how when we use the "Place Symbol" icon, it brings us to the code written 
> in "dialog_choose_component.cpp". 
> Best wishes, 
> Andrea
> ___
> 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] Gitlab issue tracker

[Jeff Young]

Never mind.  It did close it, just with a time lag from the other changes.

Cheers,
Jeff.

> On 3 Feb 2020, at 15:45, Ian McInerney  wrote:
> 
> It should automatically close them when you do that.
> 
> -Ian
> 
> On Mon, Feb 3, 2020 at 3:29 PM Jeff Young  <mailto:j...@rokeby.ie>> wrote:
> I just used:
> 
>/duplicate #2402
> 
> to mark a bug as a duplicate.  Cool.
> 
> But it didn’t close it.  Do we want duplicates closed, or was that just how 
> Launchpad did it?
> 
> Cheers,
> Jeff.
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> Post to : kicad-developers@lists.launchpad.net 
> <mailto:kicad-developers@lists.launchpad.net>
> Unsubscribe : https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> More help   : https://help.launchpad.net/ListHelp 
> <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] Gitlab issue tracker

[Jeff Young]

I just used:

   /duplicate #2402

to mark a bug as a duplicate.  Cool.

But it didn’t close it.  Do we want duplicates closed, or was that just how 
Launchpad did it?

Cheers,
Jeff.


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

[Jeff Young]

Hi guys,

Unfortunately I’ve had to cancel my FOSDEM plans due to an illness in the 
family.  (While my daughter’s college roommate is actually from Wuhan, she 
didn’t go back to China for the term break so thankfully it’s not that at 
least.)

Cheers,
Jeff.
___
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] Rebase the tree?

[Jeff Young]

FWIW, my Git tried to add the two files again (I guess from its local history). 
 I think I caught it in time and cancelled.

I then rebased without the two commits, and without Ian’s commits to remove 
them (which were also in my history).

So I think I’m up-to-date now, but if someone could check to make sure I didn’t 
bungle it again that would be great.

Cheers,
Jeff.


> On 20 Jan 2020, at 23:43, Wayne Stambaugh  wrote:
> 
> No problem.  Hopefully it wont cause too many issues for other devs who
> have to rebase any local changes.
> 
> Cheers,
> 
> Wayne
> 
> On 1/20/20 6:15 PM, Jeff Young wrote:
>> Thanks, Wayne!
>> 
>> Sorry for causing such a mess.
>> 
>> Cheers,
>> Jeff.
>> 
>> 
>>> On 20 Jan 2020, at 22:32, Wayne Stambaugh  wrote:
>>> 
>>> I found it.  I had to create a new protection for the master branch.  I
>>> pushed the changes and enabled the GitLab protection for the master
>>> branch so we should be good to resume normal development.  Thank you for
>>> the help and patience to work through this.
>>> 
>>> Cheers,
>>> 
>>> Wayne
>>> 
>>> On 1/20/20 5:27 PM, Nick Østergaard wrote:
>>>> It should be there, I am sure you are just confused by the gitlab webui.
>>>> 
>>>> It should be something along the lines of:
>>>> Settings -> Repository -> Protected branches, click expand. Set the
>>>> proper settings in the "Protect a branch" section.
>>>> 
>>>> On Mon, 20 Jan 2020 at 23:26, Wayne Stambaugh  wrote:
>>>>> 
>>>>> Well this is a kick in the teeth.  I just unprotected it and I don't see
>>>>> an option to re-enable the protection after I force the changes.
>>>>> 
>>>>> On 1/20/20 5:18 PM, Nick Østergaard wrote:
>>>>>> There is a "protected branches" section in the settings of the repo.
>>>>>> 
>>>>>> On Mon, 20 Jan 2020 at 23:18, Nick Østergaard  wrote:
>>>>>>> 
>>>>>>> You probably need to disable the option to disable force pushing on the 
>>>>>>> repo.
>>>>>>> 
>>>>>>> On Mon, 20 Jan 2020 at 23:20, Wayne Stambaugh  
>>>>>>> wrote:
>>>>>>>> 
>>>>>>>> GitLab rejected the forced push using this method.  Anyone else have 
>>>>>>>> any
>>>>>>>> ideas.  Until we get this resolved, please do not push any commits to
>>>>>>>> the master branch.
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> 
>>>>>>>> Wayne
>>>>>>>> 
>>>>>>>> On 1/20/20 5:13 PM, Wayne Stambaugh wrote:
>>>>>>>>> Please do not push anything to the master branch or perform any merge
>>>>>>>>> requests until I push the rebase the master branch to prevent any 
>>>>>>>>> commit
>>>>>>>>> losses because forcing a push will wipe out any changes.  I ran the 
>>>>>>>>> git
>>>>>>>>> command suggested by Simon and it seems to have the desired results 
>>>>>>>>> but
>>>>>>>>> I have no idea how this is going to play out so I'm making a backup
>>>>>>>>> clone of master just in case things go sideways.  I'll ping everyone
>>>>>>>>> once I have pushed the rebase.  Thank you for your cooperation and I
>>>>>>>>> apologize for whatever pain and agony this causes.  Hopefully we will
>>>>>>>>> never make this mistake again.
>>>>>>>>> 
>>>>>>>>> Cheers,
>>>>>>>>> 
>>>>>>>>> Wayne
>>>>>>>>> 
>>>>>>>>> On 1/18/20 7:29 AM, Simon Richter wrote:
>>>>>>>>>> Hi,
>>>>>>>>>> 
>>>>>>>>>> On 17.01.20 19:14, Simon Richter wrote:
>>>>>>>>>> 
>>>>>>>>>>> 1. "git rebase -i origin/master"
>>>>>>>>>>> 2. in the editor, if they are present, remove the lines
>>>>>>>>>>> 
>>>>>>>>>>>   pick ea31730b4 Handle error returns from lstat.
>>>>

Re: [Kicad-developers] Rebase the tree?

[Jeff Young]

Thanks, Wayne!

Sorry for causing such a mess.

Cheers,
Jeff.


> On 20 Jan 2020, at 22:32, Wayne Stambaugh  wrote:
> 
> I found it.  I had to create a new protection for the master branch.  I
> pushed the changes and enabled the GitLab protection for the master
> branch so we should be good to resume normal development.  Thank you for
> the help and patience to work through this.
> 
> Cheers,
> 
> Wayne
> 
> On 1/20/20 5:27 PM, Nick Østergaard wrote:
>> It should be there, I am sure you are just confused by the gitlab webui.
>> 
>> It should be something along the lines of:
>> Settings -> Repository -> Protected branches, click expand. Set the
>> proper settings in the "Protect a branch" section.
>> 
>> On Mon, 20 Jan 2020 at 23:26, Wayne Stambaugh  wrote:
>>> 
>>> Well this is a kick in the teeth.  I just unprotected it and I don't see
>>> an option to re-enable the protection after I force the changes.
>>> 
>>> On 1/20/20 5:18 PM, Nick Østergaard wrote:
 There is a "protected branches" section in the settings of the repo.
 
 On Mon, 20 Jan 2020 at 23:18, Nick Østergaard  wrote:
> 
> You probably need to disable the option to disable force pushing on the 
> repo.
> 
> On Mon, 20 Jan 2020 at 23:20, Wayne Stambaugh  
> wrote:
>> 
>> GitLab rejected the forced push using this method.  Anyone else have any
>> ideas.  Until we get this resolved, please do not push any commits to
>> the master branch.
>> 
>> Thanks,
>> 
>> Wayne
>> 
>> On 1/20/20 5:13 PM, Wayne Stambaugh wrote:
>>> Please do not push anything to the master branch or perform any merge
>>> requests until I push the rebase the master branch to prevent any commit
>>> losses because forcing a push will wipe out any changes.  I ran the git
>>> command suggested by Simon and it seems to have the desired results but
>>> I have no idea how this is going to play out so I'm making a backup
>>> clone of master just in case things go sideways.  I'll ping everyone
>>> once I have pushed the rebase.  Thank you for your cooperation and I
>>> apologize for whatever pain and agony this causes.  Hopefully we will
>>> never make this mistake again.
>>> 
>>> Cheers,
>>> 
>>> Wayne
>>> 
>>> On 1/18/20 7:29 AM, Simon Richter wrote:
 Hi,
 
 On 17.01.20 19:14, Simon Richter wrote:
 
> 1. "git rebase -i origin/master"
> 2. in the editor, if they are present, remove the lines
> 
>pick ea31730b4 Handle error returns from lstat.
>pick e83420f19 Remove file accidentally commited in ea31730b4
>pick e27e6ee16 Also catch null dereference in case wxASSERT was 
> skipped.
>pick e1925b89c Remove file accidentally added in e27e6ee1
> 
> 3. save and exit
 
 Even less interactive:
 
git filter-branch \
--prune-empty \
--index-filter \
'git rm --cached --ignore-unmatch common/libcommon.a.*' \
9df2cfb32..HEAD
 
 This rewrites the current branch to a state where the files were never
 added, and removes the now-empty correction commits. The SHA1 sums in
 the new branch are different, but as the commit contents are identical,
 rebasing feature branches then goes smoothly even from the gitlab GUI.
 
 If you rebased a branch containing the offending commits on top of a
 cleaned one, this generates four commits adding and removing the files
 with no further changes, and the filter-branch commit above then 
 reduces
 these to no-ops and removes the commits.
 
 A simple test in gitlab *merge request is descended from e1925b89c"
 could identify merge requests that would need to be rewritten.
 
   Simon
 
 
 ___
 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] Bug in the new RTREE stuff

[Jeff Young]

Hi Seth,

I found an odd bug in the new RTREE stuff:

Open a schematic.  Click on a symbol’s reference.  It gets highlighted.

Now nudge it my pressing M and then one of the arrow keys.

Click on something else and then try to select the reference again.  You’ll get 
the disambiguation menu because there are now 2 items in the RTREE (or at least 
the COLLECTOR is returning 2 copies of the same EDA_ITEM pointer).

Let me know if this doesn’t reproduce easily and I’ll send you my schematic.

Cheers,
Jeff.
___
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] Coverity heads-up

[Jeff Young]

Hi Wayne,

The main one that permeates the code is CONFIG_PARAM_ARRAY.  It doesn't use any 
of the boost::ptr_array fancy stuff.

We don’t currently catch /any/ of the exceptions thrown by boost for this data 
structure, so that part is unchanged.  What does change is the signal-to-noise 
ratio out of Coverity.

I was also going to do SCH_SHEET_PINS, which is the same, but has much less 
widespread use.

Cheers,
Jeff.


> On 12 Jan 2020, at 13:21, Wayne Stambaugh  wrote:
> 
> Hi Jeff,
> 
> We should probably discuss this a bit before you spend any time on it.
> The boost pointer containers do a lot of housekeeping under the hood
> that the standard c++ containers do not.  This means that all of the
> object cloning behavior automatically handled by the boost pointer
> containers will have to be duplicated.  How do plan on handling out of
> memory errors which I believe is the only exception that boost pointer
> containers throw?  Ignoring out of memory errors is not an acceptable
> option.  These issues will need to be address in order to convert over
> to the standard c++ containers.
> 
> Cheers,
> 
> Wayne
> 
> On 1/12/20 7:34 AM, Jeff Young wrote:
>> I’ve given up chasing down all the places where we fail to catch boost 
>> exceptions.
>> 
>> I’m removing boost::ptr_vector in favour of std::vector (which boost 
>> uses under the hood anyway).
>> ___
>> 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] Coverity heads-up

[Jeff Young]

I’ve given up chasing down all the places where we fail to catch boost 
exceptions.

I’m removing boost::ptr_vector in favour of std::vector (which boost 
uses under the hood anyway).
___
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] Coverity finds an ugly bug in wxWidgets

[Jeff Young]

I agree with Ian — looks like a false positive on closer inspection.

The cost of requiring braces on single-line statements is one of a reduction in 
signal-to-noise ratio (and I suppose less fitting on the screen).

Cheers,
Jeff.


> On 12 Jan 2020, at 01:32, Bevan Weiss  wrote:
> 
> Is there any harm in having braces for each if / else / for / while statement 
> (regardless of if it’s single line or not)?
> There is the possibility of harm in not doing it, so it seems that adding it 
> to the code style rules, would be prudent.
>  
> That Coverity is throwing a positive at this implies that it is not ‘good’ 
> coding practise in this instance (given it’s a macro being called, and the 
> macro could easily expand to something which causes issues in the Kicad 
> codebase, but nowhere else).
>  
> -  Bevan
>  
> From: Kicad-developers 
>  On 
> Behalf Of Ian McInerney
> Sent: 12 January 2020 12:24
> To: Jeff Young 
> Cc: KiCad Developers 
> Subject: Re: [Kicad-developers] Coverity finds an ugly bug in wxWidgets
>  
> I thought that Wayne was agreeing with requiring them on all lengths of 
> statements (single line).
>  
> Although, now that I look at the code closer, I don't know if this is as dire 
> a problem. While it is a macro, it is defined like this:
> #define wxLogTrace
> \
> if ( !wxLog::IsLevelEnabled(wxLOG_Trace, wxLOG_COMPONENT) )   
> \
> {}
> \
> else  
> \
> wxMAKE_LOGGER(Trace).LogTrace
>  
> so it has an else statement already included in it. That means that any else 
> condition following it will be placed with the next higher level of if 
> statements outside the macro (and there is no worry about having an else-if 
> associated with this, since the else must come after all else-if statements, 
> meaning that this if condition is effectively ended).
>  
> The wxASSERT macro is an example of a case where they did introduce a guard 
> scope around the macro contents (by placing it inside a do-while loop that 
> only executes the first pass), since it is an if with only an else-if 
> statement and no else statement. If they hadn't given it that scoping, then 
> any else statements in user code that follows it would be associated with the 
> wxASSERT if statement instead.
>  
> It seems to me that on closer inspection, this may just be Coverity throwing 
> a false positive at us.
>  
> -Ian
>  
> On Sun, Jan 12, 2020 at 12:42 AM Jeff Young  <mailto:j...@rokeby.ie>> wrote:
>> We could also just require them on if/then/else statements….
>> 
>> 
>>> On 12 Jan 2020, at 00:35, Jeff Young >> <mailto:j...@rokeby.ie>> wrote:
>>>  
>>> Sure, but unless we go with Seth’s option, then it’s just going to happen 
>>> again….
>>> 
>>> 
>>>> On 11 Jan 2020, at 23:28, Wayne Stambaugh >>> <mailto:stambau...@gmail.com>> wrote:
>>>>  
>>>> I agree that adding the curly brackets would be the best option as well.
>>>> It's less than ideal but it resolves the issue.
>>>> 
>>>> On 1/11/20 6:21 PM, Ian McInerney wrote:
>>>> 
>>>>> That is probably the best option, since many things in wxWidgets are
>>>>> implemented as macros but masquerade as functions.
>>>>> 
>>>>> -Ian
>>>>> 
>>>>> On Sat, Jan 11, 2020 at 10:07 PM >>>> <mailto:s...@kipro-pcb.com>
>>>>> <mailto:s...@kipro-pcb.com <mailto:s...@kipro-pcb.com>>> wrote:
>>>>> 
>>>>>I suppose that we could update our coding policy to require braces
>>>>>even for single line statements.
>>>>> 
>>>>>-Seth
>>>>> 
>>>>>On Jan 11, 2020 1:28 PM, Jeff Young >>>> <mailto:j...@rokeby.ie>
>>>>><mailto:j...@rokeby.ie <mailto:j...@rokeby.ie>>> wrote:
>>>>> 
>>>>>This looks safe enough:
>>>>> 
>>>>>if( n_changed )
>>>>>wxLogTrace( "CN", "Cluster %p : net : %d %s\n", cluster.get(),
>>>>>cluster->OriginNet(), (const char*) 
>>>>> cluster->OriginNetName().c_str() );
>>>>>else
>>>>>wxLogTrace( "CN", "Cluster %p : nothing to propagate\n",

Re: [Kicad-developers] Coverity finds an ugly bug in wxWidgets

[Jeff Young]

We could also just require them on if/then/else statements….

> On 12 Jan 2020, at 00:35, Jeff Young  wrote:
> 
> Sure, but unless we go with Seth’s option, then it’s just going to happen 
> again….
> 
>> On 11 Jan 2020, at 23:28, Wayne Stambaugh > <mailto:stambau...@gmail.com>> wrote:
>> 
>> I agree that adding the curly brackets would be the best option as well.
>> It's less than ideal but it resolves the issue.
>> 
>> On 1/11/20 6:21 PM, Ian McInerney wrote:
>>> That is probably the best option, since many things in wxWidgets are
>>> implemented as macros but masquerade as functions.
>>> 
>>> -Ian
>>> 
>>> On Sat, Jan 11, 2020 at 10:07 PM >> <mailto:s...@kipro-pcb.com>
>>> <mailto:s...@kipro-pcb.com <mailto:s...@kipro-pcb.com>>> wrote:
>>> 
>>>I suppose that we could update our coding policy to require braces
>>>even for single line statements.
>>> 
>>>-Seth
>>> 
>>>On Jan 11, 2020 1:28 PM, Jeff Young >> <mailto:j...@rokeby.ie>
>>><mailto:j...@rokeby.ie <mailto:j...@rokeby.ie>>> wrote:
>>> 
>>>This looks safe enough:
>>> 
>>>if( n_changed )
>>>wxLogTrace( "CN", "Cluster %p : net : %d %s\n", cluster.get(),
>>>cluster->OriginNet(), (const char*) 
>>> cluster->OriginNetName().c_str() );
>>>else
>>>wxLogTrace( "CN", "Cluster %p : nothing to propagate\n", 
>>> cluster.get() );
>>> 
>>> 
>>>Sadly, the macro wxLogTrace is not parenthesized, and starts
>>>with an if statement.  So the else doesn’t go where you think it
>>>does….
>>> 
>>>Any ideas on how to fix this that don’t include constantly
>>>checking to see if new instances have been introduced?
>>> 
>>> 
>>>___
>>>Mailing list: https://launchpad.net/~kicad-developers 
>>> <https://launchpad.net/~kicad-developers>
>>>Post to : kicad-developers@lists.launchpad.net 
>>> <mailto:kicad-developers@lists.launchpad.net>
>>><mailto:kicad-developers@lists.launchpad.net 
>>> <mailto:kicad-developers@lists.launchpad.net>>
>>>Unsubscribe : https://launchpad.net/~kicad-developers 
>>> <https://launchpad.net/~kicad-developers>
>>>More help   : https://help.launchpad.net/ListHelp 
>>> <https://help.launchpad.net/ListHelp>
>>> 
>>> 
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers 
>>> <https://launchpad.net/~kicad-developers>
>>> Post to : kicad-developers@lists.launchpad.net 
>>> <mailto:kicad-developers@lists.launchpad.net>
>>> Unsubscribe : https://launchpad.net/~kicad-developers 
>>> <https://launchpad.net/~kicad-developers>
>>> More help   : https://help.launchpad.net/ListHelp 
>>> <https://help.launchpad.net/ListHelp>
>>> 
>> 
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers 
>> <https://launchpad.net/~kicad-developers>
>> Post to : kicad-developers@lists.launchpad.net 
>> <mailto:kicad-developers@lists.launchpad.net>
>> Unsubscribe : https://launchpad.net/~kicad-developers 
>> <https://launchpad.net/~kicad-developers>
>> More help   : https://help.launchpad.net/ListHelp 
>> <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] Coverity finds an ugly bug in wxWidgets

[Jeff Young]

Sure, but unless we go with Seth’s option, then it’s just going to happen 
again….

> On 11 Jan 2020, at 23:28, Wayne Stambaugh  wrote:
> 
> I agree that adding the curly brackets would be the best option as well.
> It's less than ideal but it resolves the issue.
> 
> On 1/11/20 6:21 PM, Ian McInerney wrote:
>> That is probably the best option, since many things in wxWidgets are
>> implemented as macros but masquerade as functions.
>> 
>> -Ian
>> 
>> On Sat, Jan 11, 2020 at 10:07 PM > <mailto:s...@kipro-pcb.com>
>> <mailto:s...@kipro-pcb.com <mailto:s...@kipro-pcb.com>>> wrote:
>> 
>>I suppose that we could update our coding policy to require braces
>>even for single line statements.
>> 
>>-Seth
>> 
>>On Jan 11, 2020 1:28 PM, Jeff Young > <mailto:j...@rokeby.ie>
>><mailto:j...@rokeby.ie <mailto:j...@rokeby.ie>>> wrote:
>> 
>>This looks safe enough:
>> 
>>if( n_changed )
>>wxLogTrace( "CN", "Cluster %p : net : %d %s\n", cluster.get(),
>>cluster->OriginNet(), (const char*) 
>> cluster->OriginNetName().c_str() );
>>else
>>wxLogTrace( "CN", "Cluster %p : nothing to propagate\n", 
>> cluster.get() );
>> 
>> 
>>Sadly, the macro wxLogTrace is not parenthesized, and starts
>>with an if statement.  So the else doesn’t go where you think it
>>does….
>> 
>>Any ideas on how to fix this that don’t include constantly
>>checking to see if new instances have been introduced?
>> 
>> 
>>___
>>Mailing list: https://launchpad.net/~kicad-developers
>>Post to : kicad-developers@lists.launchpad.net 
>> <mailto:kicad-developers@lists.launchpad.net>
>><mailto:kicad-developers@lists.launchpad.net 
>> <mailto:kicad-developers@lists.launchpad.net>>
>>Unsubscribe : https://launchpad.net/~kicad-developers 
>> <https://launchpad.net/~kicad-developers>
>>More help   : https://help.launchpad.net/ListHelp 
>> <https://help.launchpad.net/ListHelp>
>> 
>> 
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers 
>> <https://launchpad.net/~kicad-developers>
>> Post to : kicad-developers@lists.launchpad.net 
>> <mailto:kicad-developers@lists.launchpad.net>
>> Unsubscribe : https://launchpad.net/~kicad-developers 
>> <https://launchpad.net/~kicad-developers>
>> More help   : https://help.launchpad.net/ListHelp 
>> <https://help.launchpad.net/ListHelp>
>> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> Post to : kicad-developers@lists.launchpad.net 
> <mailto:kicad-developers@lists.launchpad.net>
> Unsubscribe : https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> More help   : https://help.launchpad.net/ListHelp 
> <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] Coverity finds an ugly bug in wxWidgets

[Jeff Young]

This looks safe enough:

if( n_changed )
wxLogTrace( "CN", "Cluster %p : net : %d %s\n", cluster.get(),
cluster->OriginNet(), (const char*) 
cluster->OriginNetName().c_str() );
else
wxLogTrace( "CN", "Cluster %p : nothing to propagate\n", cluster.get() );

Sadly, the macro wxLogTrace is not parenthesized, and starts with an if 
statement.  So the else doesn’t go where you think it does….

Any ideas on how to fix this that don’t include constantly checking to see if 
new instances have been introduced?___
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] Markdown issue

[Jeff Young]

There’s also this one in Markdown:

https://scan8.coverity.com/reports.htm#v33181/p10844/fileInstanceId=29813788=10144552=125666

> On 11 Jan 2020, at 20:32, Jeff Young  wrote:
> 
> Could someone familiar with Clipper have a look at this one:
> 
> https://scan8.coverity.com/reports.htm#v33181/p10844/fileInstanceId=29818824=10144638=102371
>  
> <https://scan8.coverity.com/reports.htm#v33181/p10844/fileInstanceId=29818824=10144638=102371>
> 
> Thanks,
> Jeff.
> ___
> 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] Clipper issue

[Jeff Young]

Could someone familiar with Clipper have a look at this one:

https://scan8.coverity.com/reports.htm#v33181/p10844/fileInstanceId=29818824=10144638=102371
 


Thanks,
Jeff.___
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] unreleased wxFormBuilder

[Jeff Young]

I think OSX was one of the laggards, but I’m now on 3.9.0.

Cheers,
Jeff.


> On 5 Jan 2020, at 12:57, Simon Richter  wrote:
> 
> Hi,
> 
> we've been asked on IRC about a dire warning "you WILL lose data if you
> save" from wxFormBuilder when opening some of the files. Apparently
> there are new fields in the XML, but the format version hasn't been
> bumped yet, because there was no new release.
> 
> Can we tighten the wxFB requirement to "3.8.0 or later releases" to
> avoid this?
> 
> Merge request moving all affected files back to a release version is at
> https://gitlab.com/kicad/code/kicad/merge_requests/45
> 
> Apparently development versions also generate output with whitespace
> errors and, in one case, compute a size differently, that might also be
> interesting to watch in the future.
> 
>   Simon
> 
> ___
> 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] Question about gerber job file numeric format

[Jeff Young]

Safer because we’ve been writing them out like that for some time.  Maybe 
someone has some huge hack that uses fixed-length regular expressions to parse 
them or something.  

In the absence of a spec, the examples are what people use.

I’m not convinced this is the best plan either — but I am convinced it’s the 
safest.

Cheers,
Jeff.


> On 24 Dec 2019, at 19:29, Jon Evans  wrote:
> 
> Why is B safer? To me, B sounds riskier as there is a chance we are throwing 
> away data. I'm not in favor of implementing B without a clear spec (and I 
> guess Ucamco would need to be involved) on what guarantees can be made.
> 
> Right now, we implement B based on some apparently arbitrary assumptions 
> about what data can be thrown away. Re-implementing the current behavior in 
> the new library would certainly be possible, I'm just not convinced that it's 
> the best plan.
> 
> -Jon
> 
> On Tue, Dec 24, 2019, 13:54 Jeff Young  <mailto:j...@rokeby.ie>> wrote:
> Safest would be (b).
> 
> We could probably do something pretty dumb (ie: set a single value in the 
> JSON printer which it uses for precision).
> 
>> On 24 Dec 2019, at 15:22, Jon Evans > <mailto:j...@craftyjon.com>> wrote:
>> 
>> Hi all,
>> 
>> The Gerber job file specification[1] says that the format follows the JSON 
>> standard, and doesn't say much else about numeric value storage.
>> 
>> But, in the examples in that spec, decimal (floating-point) values are all 
>> truncated with only a few digits after the decimal point.
>> 
>> The manual JSON generation code that exists today follows along these 
>> examples, truncating floating-point numbers using formatting like %.3f and 
>> so on.  Now I'm working on switching us over to using a library for this 
>> JSON generation, but it will output floating-point values as doubles without 
>> any such truncation.
>> 
>> For computer software reading these job files, I would guess this has no 
>> impact.  But for humans opening up the file, they may find that the numbers 
>> stored don't match their expectations.
>> 
>> What should we do about this?
>> (a) nothing, storing doubles in the file is fine
>> (b) find some way to manually truncate/round values to some precision, but 
>> still write them to the file as "decimals" -- if so, what should the spec be 
>> for this rounding / truncation?
>> (c) something else?
>> 
>> Best,
>> Jon
>> 
>> [1] 
>> https://www.ucamco.com/files/downloads/file/209/the_gerber_job_format_specification.pdf
>>  
>> <https://www.ucamco.com/files/downloads/file/209/the_gerber_job_format_specification.pdf>___
>> Mailing list: https://launchpad.net/~kicad-developers 
>> <https://launchpad.net/~kicad-developers>
>> Post to : kicad-developers@lists.launchpad.net 
>> <mailto:kicad-developers@lists.launchpad.net>
>> Unsubscribe : https://launchpad.net/~kicad-developers 
>> <https://launchpad.net/~kicad-developers>
>> More help   : https://help.launchpad.net/ListHelp 
>> <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] Question about gerber job file numeric format

[Jeff Young]

Safest would be (b).

We could probably do something pretty dumb (ie: set a single value in the JSON 
printer which it uses for precision).

> On 24 Dec 2019, at 15:22, Jon Evans  wrote:
> 
> Hi all,
> 
> The Gerber job file specification[1] says that the format follows the JSON 
> standard, and doesn't say much else about numeric value storage.
> 
> But, in the examples in that spec, decimal (floating-point) values are all 
> truncated with only a few digits after the decimal point.
> 
> The manual JSON generation code that exists today follows along these 
> examples, truncating floating-point numbers using formatting like %.3f and so 
> on.  Now I'm working on switching us over to using a library for this JSON 
> generation, but it will output floating-point values as doubles without any 
> such truncation.
> 
> For computer software reading these job files, I would guess this has no 
> impact.  But for humans opening up the file, they may find that the numbers 
> stored don't match their expectations.
> 
> What should we do about this?
> (a) nothing, storing doubles in the file is fine
> (b) find some way to manually truncate/round values to some precision, but 
> still write them to the file as "decimals" -- if so, what should the spec be 
> for this rounding / truncation?
> (c) something else?
> 
> Best,
> Jon
> 
> [1] 
> https://www.ucamco.com/files/downloads/file/209/the_gerber_job_format_specification.pdf
>  
> ___
> 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] Folks doing their own Mac builds will want to fetch from our local wxWidgets branch...

[Jeff Young]

Oops.  I use this:

../configure \
--prefix=`pwd`/../wx-bin \
--with-opengl \
--enable-aui \
--enable-html \
--enable-richtext \
--enable-stl \
--enable-debug \
--enable-debug-gdb \
--with-libjpeg=builtin \
--with-libpng=builtin \
--with-regex=builtin \
--with-libtiff=builtin \
--with-zlib=builtin \
--with-expat=builtin \
--without-liblzma \
--with-macosx-version-min=10.13 \
--enable-universal-binary=x86_64 \
CC=clang \
CXX=clang++

Note the inclusion of —enable-richtext over your version.  You need that for 
the new multi-line text editor.

Cheers,
Jeff.

> On 22 Dec 2019, at 01:22, Ian McInerney  wrote:
> 
> Jeff,
> 
> I was actually referring to the wxWidgets compilation configure commands not 
> the KiCad configure commands. I ended up fixing it by removing the 
> --enable-utf8 flag that we suggest passing into wxWidgets, overall it was:
> 
> ../configure \
> --prefix=`pwd` \
> --enable-debug \
> --with-opengl \
> --enable-aui \
> --enable-html \
> --enable-stl \
> --with-libjpeg=builtin \
> --with-libpng=builtin \
> --with-regex=builtin \
> --with-libtiff=builtin \
> --with-zlib=builtin \
> --with-expat=builtin \
> --without-liblzma \
> --with-macosx-version-min=10.14 \
> CC=clang \
>     CXX=clang++
> 
> Thanks,
> -Ian
> 
> On Sun, Dec 22, 2019 at 1:05 AM Jeff Young  <mailto:j...@rokeby.ie>> wrote:
> Hi Ian,
> 
> I’m using:
> 
> -DCMAKE_C_COMPILER=clang
> -DCMAKE_CXX_COMPILER=clang++
> -DCMAKE_OSX_DEPLOYMENT_TARGET=10.14
> -DwxWidgets_CONFIG_EXECUTABLE=/Users/jeff/kicad_dev/wxWidgets/wx-bin/bin/wx-config
> -DKICAD_SCRIPTING=ON
> -DKICAD_SCRIPTING_MODULES=OFF
> -DKICAD_SCRIPTING_WXPYTHON=OFF
> -DKICAD_USE_OCE=OFF
> -DKICAD_USE_FONT_REDUCED_SET=ON
> -DCMAKE_INSTALL_PREFIX=./bin
> -DCMAKE_BUILD_TYPE=Debug
> -DPYTHON_SITE_PACKAGE_PATH=/Users/jeff/kicad_dev/wxWidgets/wx-bin/lib/python2.7/site-packages
> 
> That’s with CLion, but it should be the same elsewhere.
> 
> Cheers,
> Jeff.
> 
> 
>> On 22 Dec 2019, at 00:11, Ian McInerney > <mailto:ian.s.mciner...@ieee.org>> wrote:
>> 
>> Jeff,
>> 
>> What configure flags are you using with our fork of wxWidgets? When I use 
>> the flags we list in the developer docs I hit the error you added about 
>> wxUSE_UNICODE_UTF8 being defined. Completely removing Unicode support also 
>> breaks KiCad builds (since that typdefs wxChar into char, and we get an 
>> error). Is there another configure flag you pass to still use Unicode by not 
>> UTF8?
>> 
>> Thanks,
>> -Ian
>> 
>> On Sat, Aug 10, 2019 at 11:18 AM Jeff Young > <mailto:j...@rokeby.ie>> wrote:
>> … and rebuild wxWidgets.
>> 
>> Cheers,
>> Jeff.
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers 
>> <https://launchpad.net/~kicad-developers>
>> Post to : kicad-developers@lists.launchpad.net 
>> <mailto:kicad-developers@lists.launchpad.net>
>> Unsubscribe : https://launchpad.net/~kicad-developers 
>> <https://launchpad.net/~kicad-developers>
>> More help   : https://help.launchpad.net/ListHelp 
>> <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] Folks doing their own Mac builds will want to fetch from our local wxWidgets branch...

[Jeff Young]

Hi Ian,

I’m using:

-DCMAKE_C_COMPILER=clang
-DCMAKE_CXX_COMPILER=clang++
-DCMAKE_OSX_DEPLOYMENT_TARGET=10.14
-DwxWidgets_CONFIG_EXECUTABLE=/Users/jeff/kicad_dev/wxWidgets/wx-bin/bin/wx-config
-DKICAD_SCRIPTING=ON
-DKICAD_SCRIPTING_MODULES=OFF
-DKICAD_SCRIPTING_WXPYTHON=OFF
-DKICAD_USE_OCE=OFF
-DKICAD_USE_FONT_REDUCED_SET=ON
-DCMAKE_INSTALL_PREFIX=./bin
-DCMAKE_BUILD_TYPE=Debug
-DPYTHON_SITE_PACKAGE_PATH=/Users/jeff/kicad_dev/wxWidgets/wx-bin/lib/python2.7/site-packages

That’s with CLion, but it should be the same elsewhere.

Cheers,
Jeff.


> On 22 Dec 2019, at 00:11, Ian McInerney  wrote:
> 
> Jeff,
> 
> What configure flags are you using with our fork of wxWidgets? When I use the 
> flags we list in the developer docs I hit the error you added about 
> wxUSE_UNICODE_UTF8 being defined. Completely removing Unicode support also 
> breaks KiCad builds (since that typdefs wxChar into char, and we get an 
> error). Is there another configure flag you pass to still use Unicode by not 
> UTF8?
> 
> Thanks,
> -Ian
> 
> On Sat, Aug 10, 2019 at 11:18 AM Jeff Young  <mailto:j...@rokeby.ie>> wrote:
> … and rebuild wxWidgets.
> 
> Cheers,
> Jeff.
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> Post to : kicad-developers@lists.launchpad.net 
> <mailto:kicad-developers@lists.launchpad.net>
> Unsubscribe : https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> More help   : https://help.launchpad.net/ListHelp 
> <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] Connection graph question

[Jeff Young]

I was going to say that if they’re now a copy we could simplify the draw code a 
bit.

But I see Wayne has already done that. :)

Cheers,
Jeff.


> On 12 Dec 2019, at 08:57, Jonatan Liljedahl  wrote:
> 
> On Thu, Dec 12, 2019 at 12:01 AM Wayne Stambaugh  wrote:
> 
>> Now that the LIB_PART of the SCH_COMPONENT is no longer a pointer link
>> but an actual copy of the library symbol, any change to the underlying
>> library symbol will result in stale pin map pointers.
> 
> I'm just curious to know, since I'm not at all familiar with this part
> of the code, why does it need to be a copy instead of a pointer? And
> is this per symbol instance in the schematic?
> 
> -- 
> /Jonatan
> http://kymatica.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] Editing stroke font

[Jeff Young]

Is there a tutorial anywhere on editing the stroke font?  We seem to be missing 
the Ω symbol….
___
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] GitLab bug workflow

[Jeff Young]

It would definitely streamline the workflow if we could be good about assigning 
milestones (and deep-six the fix-committed/fix-released tags).

> On 4 Dec 2019, at 11:16, Ian McInerney  wrote:
> 
> The plan that has been proposed here: 
> https://gitlab.com/kicad/code/kicad/wikis/Developers/Guidelines/Issue-Tracker 
> <https://gitlab.com/kicad/code/kicad/wikis/Developers/Guidelines/Issue-Tracker>
>  is that bugs in fix-committed, fix-released, fixed and duplicate will be in 
> the closed status. I had added the fix-committed/fix-released to our GitLab 
> tags so we can still keep track of if something has actually been released. 
> If we promise to be good about assigning bugs to milestones, then we could 
> just use milestones being released to mark them as released/committed (an 
> open milestone is not released, a closed one is).
> 
> Speaking of which @Maciej Suminski <mailto:maciej.sumin...@cern.ch> can you 
> modify the current janitor "nudger" that emails people if they close an issue 
> with no milestone to work with GitLab?
> 
> -Ian
> 
> On Wed, Dec 4, 2019 at 11:10 AM Jeff Young  <mailto:j...@rokeby.ie>> wrote:
> Forgive me if this was communicated and I missed it, but when do we 
> transition a GitLab bug from Open to Closed?  At Fix-Committed or 
> Fix-Released?
> 
> And are those two tags just for migrated bugs, or will we continue to use 
> them for new bugs?
> 
> Thanks,
> Jeff.
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> Post to : kicad-developers@lists.launchpad.net 
> <mailto:kicad-developers@lists.launchpad.net>
> Unsubscribe : https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> More help   : https://help.launchpad.net/ListHelp 
> <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] GitLab bug workflow

[Jeff Young]

Hmm… just noticed that some of the non-released bugs are coming in a Closed, so 
we appear to be going from Open to Closed at Fix-Committed.

So do we still want to add the Fix-Committed tag to new bugs, or just Close 
them?


> On 4 Dec 2019, at 11:09, Jeff Young  wrote:
> 
> Forgive me if this was communicated and I missed it, but when do we 
> transition a GitLab bug from Open to Closed?  At Fix-Committed or 
> Fix-Released?
> 
> And are those two tags just for migrated bugs, or will we continue to use 
> them for new bugs?
> 
> Thanks,
> Jeff.
> ___
> 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] GitLab bug workflow

[Jeff Young]

Forgive me if this was communicated and I missed it, but when do we transition 
a GitLab bug from Open to Closed?  At Fix-Committed or Fix-Released?

And are those two tags just for migrated bugs, or will we continue to use them 
for new bugs?

Thanks,
Jeff.
___
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] Strokefont change from std::deque to std::vector

[Jeff Young]

OK, my stuff is pushed

> On 3 Dec 2019, at 17:44, Jeff Young  wrote:
> 
> He he… I had sort of the same idea, only I’m building it lazily at runtime.  
> But I think your idea would be even better.
> 
> Since I’ve already made the changes to have STROKE_FONT use const pointers to 
> the data structures, let me merge in first and then you can move it to 
> compile-time.
> 
> Cheers,
> Jeff.
> 
> 
>> On 3 Dec 2019, at 17:40, Seth Hillbrand > <mailto:s...@kipro-pcb.com>> wrote:
>> 
>> On 12/3/19 7:27 AM, Jeff Young wrote:
>>> Hi Seth,
>>> 
>>> Trying to keep track of lengths is going to be ugly.  I did re-write the 
>>> bounding-box calc (which saves a bunch), and re-mapped the initialisation 
>>> to use stack storage until all the points had been allocated (which saves a 
>>> little).
>>> 
>>> But it’s still too slow (especially when you try to edit a pad).
>>> 
>>> A glyph is an array of strokes; a stroke is an array of points.  Do you 
>>> remember which was giving the issue?  (Or was it both?)
>>> 
>>> Changing the glyph back to a deque (and leaving the strokes vectors) would 
>>> probably alleviate much of the performance hit — but I’m not sure if it 
>>> would bring back the memory issues or not.
>>> 
>>> Cheers,
>>> Jeff.
>> 
>> Hi Jeff-
>> 
>> How about this solution:
>> 
>> There's no reason we need to keep generating Hershey.  It is bulky, we can't 
>> read it by a human anyway and we waste time reloading.
>> 
>> Instead, I'll adjust the generation script to build the 
>> vector>> structure as a constant.  Then we can just 
>> reference it and it is converted at compile time.
>> 
>> If you're OK with this plan, I'll do the adjustment.
>> 
>> Best-
>> Seth
>> 
>> -- 
>>  
>> Seth Hillbrand
>> Lead Developer
>> +1-530-302-5483‬ 
>> Davis, CA
>> www.kipro-pcb.com <https://www.kipro-pcb.com/>i...@kipro-pcb.com 
>> <mailto:i...@kipro-pcb.com>
>>  <https://twitter.com/KiProEDA>   <https://twitter.com/KiProEDA>  
>> <https://www.linkedin.com/company/kicad>   
>> <https://www.linkedin.com/company/kicad>
> ___
> 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] Strokefont change from std::deque to std::vector

[Jeff Young]

He he… I had sort of the same idea, only I’m building it lazily at runtime.  
But I think your idea would be even better.

Since I’ve already made the changes to have STROKE_FONT use const pointers to 
the data structures, let me merge in first and then you can move it to 
compile-time.

Cheers,
Jeff.


> On 3 Dec 2019, at 17:40, Seth Hillbrand  wrote:
> 
> On 12/3/19 7:27 AM, Jeff Young wrote:
>> Hi Seth,
>> 
>> Trying to keep track of lengths is going to be ugly.  I did re-write the 
>> bounding-box calc (which saves a bunch), and re-mapped the initialisation to 
>> use stack storage until all the points had been allocated (which saves a 
>> little).
>> 
>> But it’s still too slow (especially when you try to edit a pad).
>> 
>> A glyph is an array of strokes; a stroke is an array of points.  Do you 
>> remember which was giving the issue?  (Or was it both?)
>> 
>> Changing the glyph back to a deque (and leaving the strokes vectors) would 
>> probably alleviate much of the performance hit — but I’m not sure if it 
>> would bring back the memory issues or not.
>> 
>> Cheers,
>> Jeff.
> 
> Hi Jeff-
> 
> How about this solution:
> 
> There's no reason we need to keep generating Hershey.  It is bulky, we can't 
> read it by a human anyway and we waste time reloading.
> 
> Instead, I'll adjust the generation script to build the 
> vector>> structure as a constant.  Then we can just 
> reference it and it is converted at compile time.
> 
> If you're OK with this plan, I'll do the adjustment.
> 
> Best-
> Seth
> 
> -- 
>  
> Seth Hillbrand
> Lead Developer
> +1-530-302-5483‬ 
> Davis, CA
> www.kipro-pcb.com <https://www.kipro-pcb.com/>i...@kipro-pcb.com 
> <mailto:i...@kipro-pcb.com>
>  <https://twitter.com/KiProEDA>   <https://twitter.com/KiProEDA>   
> <https://www.linkedin.com/company/kicad>   
> <https://www.linkedin.com/company/kicad>
___
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] Strokefont change from std::deque to std::vector

[Jeff Young]

Hi Simon,

I’m already doing that — it helps a little but less than I thought it would.

Cheers,
Jeff.

PS: I’m trying out another version which pre-flights the number of strokes, but 
not the number of points in each stroke.

> On 3 Dec 2019, at 15:42, Simon Richter  wrote:
> 
> Hi,
> 
> On Tue, Dec 03, 2019 at 03:27:26PM +0000, Jeff Young wrote:
> 
>> Changing the glyph back to a deque (and leaving the strokes vectors) would 
>> probably alleviate much of the performance hit — but I’m not sure if it 
>> would bring back the memory issues or not.
> 
> Would it make sense to build it up as a list or deque, perhaps with a
> custom allocator, and then copy the contents to a vector once the length is
> known?
> 
>   Simon
> 
> ___
> 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] Strokefont change from std::deque to std::vector

[Jeff Young]

Hi Seth,

Trying to keep track of lengths is going to be ugly.  I did re-write the 
bounding-box calc (which saves a bunch), and re-mapped the initialisation to 
use stack storage until all the points had been allocated (which saves a 
little).

But it’s still too slow (especially when you try to edit a pad).

A glyph is an array of strokes; a stroke is an array of points.  Do you 
remember which was giving the issue?  (Or was it both?)

Changing the glyph back to a deque (and leaving the strokes vectors) would 
probably alleviate much of the performance hit — but I’m not sure if it would 
bring back the memory issues or not.

Cheers,
Jeff.


> On 3 Dec 2019, at 00:57, Seth Hillbrand  wrote:
> 
> On 12/2/19 3:45 PM, Jeff Young wrote:
>> Hi Seth,
>> 
>> What was the reason for the change from std::deque to std::vector?  Building 
>> the stroke font is now accounting for 50% of document load time (I think 
>> because we’re using a 2D vector so that any resize of any constituent vector 
>> has to reallocate the whole shebang).
>> 
>> We also load the font twice, which is something I’ll look at fixing 
>> irrespective of the above.
>> 
>> Thanks,
>> Jeff.
>> 
>> 
> 
> Hmm... That's true.  As we are allocating, we don't have pre-knowledge of the 
> Hershey point list lengths, so the vectors get resized as we add.  How much 
> will depend a bit on implementation.  But we'll gain speed by cycling once 
> over the font and building our length knowledge first.
> 
> The vector change was due to the deque overhead.  A deque takes a fair amount 
> of memory for the structure.  We generate a bunch of vectors with only 3-4 
> elements and the size of the deque is dominated by the structure overhead.  
> There was so much that JP's machine was crashing with the extra CJK fonts.
> 
> Best-
> Seth
> 
> -- 
>  
> Seth Hillbrand
> Lead Developer
> +1-530-302-5483‬ 
> Davis, CA
> www.kipro-pcb.com <https://www.kipro-pcb.com/>i...@kipro-pcb.com 
> <mailto:i...@kipro-pcb.com>
>  <https://twitter.com/KiProEDA>   <https://twitter.com/KiProEDA>   
> <https://www.linkedin.com/company/kicad>   
> <https://www.linkedin.com/company/kicad>___
> 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] Project leader announcement

[Jeff Young]

Excellent news!

> On 3 Dec 2019, at 14:39, Seth Hillbrand  wrote:
> 
> On 2019-12-03 06:28, Wayne Stambaugh wrote:
>> I wanted keep everyone up to date with my employment situation since my
>> termination from WIT.  I am excited to announce that I have joined the
>> KiCad Services Corporation[1] which will allow me to earn income while
>> still working on KiCad as much as possible.  You can see my interview
>> video[2] with founder Seth Hillbrand if you are interested.  If you know
>> anyone looking for paid commercial support of the KiCad, please have
>> them take a look at the services offered by the KiCad Services Corp.
>> I'm hopeful that joining KiCad Services Corp will allow me to continue
>> working on KiCad full time.
>> Cheers,
>> Wayne
>> [1]: https://www.kipro-pcb.com/
>> [2]: https://www.youtube.com/watch?v=X4wMtCqVUQE=youtu.be
> 
> Welcome Wayne!  It's great to have you on board.  I'm looking forward to 
> doing great things with KiCad and the supporting Corporation.
> 
> Seth
> 
> Seth Hillbrand
> KiCad Services Corporation
> https://www.kipro-pcb.com 
> +1 530 302 5483 | +1 212 603 9372
> 
> ___
> 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] Strokefont change from std::deque to std::vector

[Jeff Young]

Hi Seth,

What was the reason for the change from std::deque to std::vector?  Building 
the stroke font is now accounting for 50% of document load time (I think 
because we’re using a 2D vector so that any resize of any constituent vector 
has to reallocate the whole shebang).

We also load the font twice, which is something I’ll look at fixing 
irrespective of the above.

Thanks,
Jeff.___
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] Git fixes migration

[Jeff Young]

No worries.  I’ll check them manually after the migration is complete.

Cheers,
Jeff.


> On 2 Dec 2019, at 23:21, Maciej Suminski  wrote:
> 
> Now I realize that I should have warned you: 'git fixes' is already set up 
> for Gitlab. I thought it makes sense since Gitlab is now the official 
> repository.
> Janitor observes the Launchpad branches, so as long as a commit reaches the 
> Launchpad repository, it *should* work fine.
> 
> Cheers,
> Orson
> 
> On 12/2/19 2:45 PM, Wayne Stambaugh wrote:
>> That's a good question.  I don't know if using the launchpad janitor tag
>> will close the bug now that the launchpad repo is a mirror.  You can
>> push it to the gitlab repo an see what happens.  If it doesn't work, you
>> will have to manually change the bug status in Launchpad.it s
>> On 12/2/19 8:32 AM, Jeff Young wrote:
>>> So I just fixed a bug.  Can I still use the Launchpad ID in a “git fixes” 
>>> statement, or do I need to wait until it has a git number?
>>> ___
>>> 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] v6 roadmap and schedule (was Re: 5.1.5 released.)

[Jeff Young]

There’s some great stuff in here though on some of the topics we are doing.  
I’m not sure how best to work in to the email discussions that are bound to 
come up, but I’ve flagged it in my email inbox.

Cheers,
Jeff.

Oh, and for what it’s worth, our main UI guy spent 25 years at Adobe, and uses 
JetBrains for Kicad development. ;)

> On 2 Dec 2019, at 18:56, Wayne Stambaugh  wrote:
> 
> Hi Ruth,
> 
> Feedback is always welcome.  For V6, I'm trying to keep us on track for
> the road map items as they stand.  Rehashing these goals at the moment
> would be counter productive but I'm certainly willing to entertain your
> suggestion once we've released V6.  For future reference, please post
> one email per topic.  I know this is more work from your perspective but
> there is no way to manage an email thread covering every topic you
> mentioned.
> 
> Thanks,
> 
> Wayne
> 
> On 11/29/19 1:28 PM, Ruth Ivimey-Cook wrote:
>> Hi,
>> 
>> On 29/11/2019 13:56, Wayne Stambaugh wrote:
>>> It's not as up to date as it should be but it's pretty close
>>> 
>>> https://docs.kicad-pcb.org/doxygen/v6_road_map.html
>> 
>> I'm hoping some feedback on these goals would be welcomed:
>> 
>> 
>>>User Interface Modernization
>>> 
>>> *Goal:*
>>> 
>>> Give KiCad a more modern user interface with dockable tool bars and
>>> windows. Create perspectives to allow users to arrange dockable
>>> windows as they prefer.
>>> 
>> Even though v5.1 is better than v5, and v5 better than v4, this is welcomed.
>> 
>>> *Task:*
>>> 
>>>  * Take advantage of the advanced UI features in wxAui such as
>>>detaching and hiding.
>>> 
>> The Adobe tools (Photoshop, InDesign et al) have the idea of preset
>> workspaces, which are not prescriptive and do not imply anything about
>> the way the product works, but are simply arrangements of windows, etc,
>> that make sense for the named tasks. I find them helpful when I want to
>> "switch mode", whereas I'm happy to do manual changes inline as I work.
>> I would encourage KiCad to explore this idea too.
>> 
>>>  * Develop a global shortcut manager that allows the user assign
>>>arbitrary shortcuts for any tool or action.
>>> 
>> Definitely looking forward to this as well. Can I suggest, as for
>> workspaces, that keymaps can be grouped and labelled and easily switched
>> between, so that we can have the legacy keymap for those who don't want
>> to change, the new keymap, and named custom keymaps. This will make life
>> so much easier for users and devs alike.
>> 
>> I would most *definitely recommend* anyone doing UI work on either of
>> these topics to explore the JetBrains tools, some of which (e.g.
>> PyCharm) have free editions. I very much like their way of setting up
>> Keymaps (Preferences), and of being able to search for an action by name
>> and invoke it immediately and/or see where it is in the menu (Help
>> menu). I also really like the "search for setting" implementation in the
>> Preferences window.
>> 
>> I'm not so keen on the JetBrains implementation of floating / docked etc
>> windows, which I think was much better done in Visual Studio
>> (traditional version). Adobe does several things right in this area as
>> well, and IMO it's not clear whether Visual Studio or Photoshop has the
>> better "docking window" implementation.
>> 
>> See:
>> 
>>  * https://www.jetbrains.com/pycharm/download/  (PyCharm Community ed.
>>is free to use).
>>  * https://visualstudio.microsoft.com/  (Visual Studio Community 2019)
>>  * https://www.adobe.com/uk/products/photoshop/free-trial-download.html  
>> (Adobe
>>Photoshop CC free trial download)
>> 
>> 
>>>Implement Sweet (S-Expression) Symbol Libraries  / + / 
>>>S-Expression File Format
>>> 
>>> *Goal:*
>>> 
>>> Make schematic file format more readable, add new features, and take
>>> advantage of the s-expression parser and formatter capability used in
>>> Pcbnew.
>>> 
>> Just a comment about the file format: *please*, please ensure that there
>> is a defined order for writing 'things' in a collection to file.
>> 
>> This is so that loading a project, making some change, and then saving
>> it again only changes lines in the output file(s) directly related to to
>> change. This so that source control tools like git can track actual
>> differences, without being obscured by other, inconsequential ones.
>> 
>> I say this because it seems to me that v5 reads into an unordered
>> collection and therefore writes it out unordered, so writing the "same"
>> file again may change 90% of it by "chance".
>> 
>> To do this, I think the various file writer implementations must:
>> 
>>   - for every collection/list/set/group, the order of things read in
>> from a file must be retained when written out.
>> 
>>   - even when there is flexibility in the file format to reorder data
>> chunks, that once a file is read in this order does not change when
>> written again (of course, it could be the same order every time).
>> 
>>   - items in the file 

[Kicad-developers] Git fixes migration

[Jeff Young]

So I just fixed a bug.  Can I still use the Launchpad ID in a “git fixes” 
statement, or do I need to wait until it has a git number?
___
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] Which GitLab issues tracker are we going to use?

[Jeff Young]

Ahh… yes, if you try to log a but at the top level you get a green button 
“Select project to create issue”.

Cheers,
Jeff.


> On 1 Dec 2019, at 20:54, Ian McInerney  wrote:
> 
> Issues must live in a project, so the issues for the KiCad code must go in 
> the Kicad/code/kicad list. The other lists (KiCad and KiCad/code) just show 
> all issues for all the projects underneath that folder.
> 
> -Ian
> 
> On Sun, Dec 1, 2019 at 8:51 PM Jeff Young  <mailto:j...@rokeby.ie>> wrote:
> Kicad, Kicad/code or Kicad/code/kicad?
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> Post to : kicad-developers@lists.launchpad.net 
> <mailto:kicad-developers@lists.launchpad.net>
> Unsubscribe : https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> More help   : https://help.launchpad.net/ListHelp 
> <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] Which GitLab issues tracker are we going to use?

[Jeff Young]

Kicad, Kicad/code or Kicad/code/kicad?

___
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] Fix lp:1849376

[Jeff Young]

Didn’t someone do a couple of icons recently that looked nice?  Ian or Michael 
maybe?

(I was hoping to get a new icon for something or another too, although I can’t 
remember what now….)

> On 27 Nov 2019, at 08:00, Franck Jullien  wrote:
> 
>> I took a look at the intersheet reference patch and it looks like a nice
>> addition.  It will need to wait until after the schematic file format
>> has been updated as it does introduce new functionality to the format.
>> We won't be adding new functionality to the existing, legacy schematic
>> file format.  So hold on to the patch for now and after the new format
>> has been merged and the dust settles a bit, you can re-propose it.
>> 
> 
> Ok, no problem.
> 
>> A couple things to change in it when you do:
>> - Please add CC-BY-SA-4.0 license to SVG you've created.  This goes in
>> the metadata and is an option in newer Inkscapes.
> 
> Do we have someone good at icon design ?
> Because I think this icon should be redraw. I'm not an artist :)
> 
>> - Code style places a space before the if-blocks
>> 
> 
> Ok. However, I ran check_coding.sh and it didn't find this particular problem.
> 
>> I haven't had a chance to look over the navigator yet but I may be able
>> to get to it next week unless someone else has time first.
>> 
> 
> No problem.
> 
> Thanks for your time.
> 
> Franck.
> 
> ___
> 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] New Official Bug Tracker Tags

[Jeff Young]

FWIW, in the code footprint is often abbreviated as fp, but symbol is rarely 
abbreviated.

> On 26 Nov 2019, at 20:45, Ian McInerney  wrote:
> 
> I do like fp-editor and sym-editor better. Note that for consistency with the 
> other multiword tags for GitLab, I will use a hyphen.
> 
> -Ian
> 
> On Tue, 26 Nov 2019, 8:07 p.m. Jeff Young,  <mailto:j...@rokeby.ie>> wrote:
> I would go with either historic (modedit and libedit) or current (fp_editor 
> and symbol_editor).
> 
> Mixing the two would be particularly obscure.
> 
> Cheers,
> Jeff.
> 
> > On 26 Nov 2019, at 19:40, Wayne Stambaugh  > <mailto:stambau...@gmail.com>> wrote:
> > 
> > 
> > 
> > On 11/26/19 2:20 PM, Ian McInerney wrote:
> >> I would like to introduce two new official tags on the bug tracker to
> >> track issues relating to the symbol and footprint editors. Currently we
> >> are tracking these under the eeschema and pcbnew tags respectively, but
> >> those are growing quite large (pcbnew has over 500). I think tracking
> >> these two tools under separate tags would help, since then we can more
> >> easily locate bugs/wishlist items for them.
> >> 
> >> I am thinking the footprint editor should be *modedit*, and my initial
> >> proposal for the symbol editor is *libedit*. I don't really like libedit
> >> though, since technically footprints also live in a library (but the
> >> code calls it libedit). Anyone have a better suggestion for its tag?
> > 
> > How about "symedit", short for symbol editor.  Honestly I would prefer
> > "fpedit" over "modedit" since we really don't refer to footprints as
> > modules any more.
> > 
> >> 
> >> Once we sort out the tag, and if no one objects, I will go through and
> >> update the tags after the GitLab transition is done.
> >> 
> >> -Ian
> >> 
> >> ___
> >> Mailing list: https://launchpad.net/~kicad-developers 
> >> <https://launchpad.net/~kicad-developers>
> >> Post to : kicad-developers@lists.launchpad.net 
> >> <mailto:kicad-developers@lists.launchpad.net>
> >> Unsubscribe : https://launchpad.net/~kicad-developers 
> >> <https://launchpad.net/~kicad-developers>
> >> More help   : https://help.launchpad.net/ListHelp 
> >> <https://help.launchpad.net/ListHelp>
> >> 
> > 
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers 
> > <https://launchpad.net/~kicad-developers>
> > Post to : kicad-developers@lists.launchpad.net 
> > <mailto:kicad-developers@lists.launchpad.net>
> > Unsubscribe : https://launchpad.net/~kicad-developers 
> > <https://launchpad.net/~kicad-developers>
> > More help   : https://help.launchpad.net/ListHelp 
> > <https://help.launchpad.net/ListHelp>
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> Post to : kicad-developers@lists.launchpad.net 
> <mailto:kicad-developers@lists.launchpad.net>
> Unsubscribe : https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> More help   : https://help.launchpad.net/ListHelp 
> <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] GitLab migration

[Jeff Young]

OK, I’ve enabled 2FA.  Do I need to do something to get added back to the 
project?  (When I go to members, all I see are the bot, Seth and Wayne.)

Cheers,
Jeff.


> On 26 Nov 2019, at 19:36, Wayne Stambaugh  wrote:
> 
> While wearing my official project leader hat, I'm not going to force
> anyone to use 2FA but I suggest you do.  If you are unwilling to use
> 2FA, pleasing enable commit notifications for the main repo master and
> 5.1 branches.  I'm figuring if you get a commit notification in your
> name that you did not do, you will notify the lead dev team immediately
> so we can resolve it.
> 
> Cheers,
> 
> Wayne
> 
> On 11/26/19 8:13 AM, Jeff Young wrote:
>> Was there a resolution on the 2FA question?  (I used to have to use it for 
>> Adobe’s VPN and hated it, but it is what it is.)
>> 
>> I assume git merges will still go through SSH and not require 2FA either way?
>> 
>> Cheers,
>> Jeff.
>> ___
>> 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] New Official Bug Tracker Tags

[Jeff Young]

I would go with either historic (modedit and libedit) or current (fp_editor and 
symbol_editor).

Mixing the two would be particularly obscure.

Cheers,
Jeff.

> On 26 Nov 2019, at 19:40, Wayne Stambaugh  wrote:
> 
> 
> 
> On 11/26/19 2:20 PM, Ian McInerney wrote:
>> I would like to introduce two new official tags on the bug tracker to
>> track issues relating to the symbol and footprint editors. Currently we
>> are tracking these under the eeschema and pcbnew tags respectively, but
>> those are growing quite large (pcbnew has over 500). I think tracking
>> these two tools under separate tags would help, since then we can more
>> easily locate bugs/wishlist items for them.
>> 
>> I am thinking the footprint editor should be *modedit*, and my initial
>> proposal for the symbol editor is *libedit*. I don't really like libedit
>> though, since technically footprints also live in a library (but the
>> code calls it libedit). Anyone have a better suggestion for its tag?
> 
> How about "symedit", short for symbol editor.  Honestly I would prefer
> "fpedit" over "modedit" since we really don't refer to footprints as
> modules any more.
> 
>> 
>> Once we sort out the tag, and if no one objects, I will go through and
>> update the tags after the GitLab transition is done.
>> 
>> -Ian
>> 
>> ___
>> 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] GitLab migration

[Jeff Young]

Was there a resolution on the 2FA question?  (I used to have to use it for 
Adobe’s VPN and hated it, but it is what it is.)

I assume git merges will still go through SSH and not require 2FA either way?

Cheers,
Jeff.
___
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] Using OPT types

[Jeff Young]

Personally I hate OPT (because it’s somewhat harder to read and 
more-than-somewhat harder to debug).

I also dislike auto, except in the case of stl::’s overly-verbose iterators.  
Again, they make the code harder to read more often than not.

Maybe I’m just showing my age….

> On 24 Nov 2019, at 11:13, Ian McInerney  wrote:
> 
> What is the current consensus on using OPT types in the code? I know there 
> are some instances where we are already using them from the Boost library 
> (since our C++ version isn't high enough to include them), but is that 
> considered a good type to use more of?
> 
> I am curious, because I am thinking of replumbing the position storage in the 
> tool events to use OPTs for the position, because that will allow for cleaner 
> handling of the position in the tools, and also because I need to pass the 
> positions into the selection routines, and being able to pass an OPT will 
> greatly simplify things (I think).
> 
> -Ian
> ___
> 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 joins the Linux Foundation

[Jeff Young]

Addition.  Folks are free to continue to use CERN if they want.

> On 22 Nov 2019, at 19:39, Mark Roszko  wrote:
> 
> > I need to add a "Donate via Linux Foundation" button to the KiCad
> website main page.  
> 
> But is it in addition to or to replace CERN?
> 
> 
> 
> On Fri, Nov 22, 2019 at 12:03 PM Wayne Stambaugh  > wrote:
> I just pushed a blog post to the KiCad website that KiCad has joined the
> Linux Foundation so consider this the official announcement.  The
> project did this to give donors a choice of how they want to donate to
> KiCad and it gives us some more flexibility on how we can spend donation
> money.  This does not in any way change our relationship with CERN and
> you can continue to donate via CERN if that is your preference.  You
> should be seeing announcements from the Linux Foundation shortly.
> 
> I need to add a "Donate via Linux Foundation" button to the KiCad
> website main page.  If someone would please point me to the correct
> place in the website source where I need to do this, I would appreciate
> it.  If you would rather do it yourself, the KiCad LF donation link is
> https://funding.communitybridge.org/projects/kicad 
> .
> 
> Who has the account login information for the KiCad Facebook page?  I
> didn't create this so it would be nice if I had edit access so I could
> post announcements there instead of asking someone else to do it.
> 
> I hope joining the Linux Foundation will improve our potential donor
> visibility so we can continue to grow the KiCad project.  Thank you all
> for your continued support.
> 
> 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 
> 
> 
> 
> -- 
> 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

Re: [Kicad-developers] Back annotate references from PCB

[Jeff Young]

Hi Brian,

If you double-click into the left channel you’ll see Q101.  If you double-click 
into the right, you’ll see Q201.  So it looks like there are two.  But if you 
edit either one it goes back to a single file so both will be changed.

(To be honest I’ve never used this feature, so I’m not 100% sure the above is 
correct.  But I’m pretty sure.)

My guess is there’s a tutorial somewhere; perhaps Wayne or JP could comment?

Cheers,
Jeff.


> On 22 Nov 2019, at 19:42, Brian  wrote:
> 
> Hi Jeff,
> 
> Thanks for helping me understand this.  So how would someone looking at the 
> schematic know that this one symbol represents both Q101 and Q201?  For that 
> matter, if there's some instructions or a tutorial about creating a situation 
> like this (one schematic drawing representing multiple instances of the 
> subcircuit on the pcb), I'd be interested to learn it.  I have a couple 
> projects in the pipeline where I might find this feature useful; in the past, 
> I've manually copy/pasted sections of a schematic to repeat subcircuits.
> 
> Thanks,
> -Brian
> 
> On 11/22/19 2:37 PM, Jeff Young wrote:
>> Hi Brian,
>> 
>> Imagine you’re doing an audio amplifier.  Your main schematic sheet has 4 
>> subsheets: PSU, control logic, left channel and right channel.  Both left 
>> channel and right channel point to the same sub-page.  So there’s a single 
>> schematic symbol for each part in the left & right channel, which gets 
>> annotated as two different references (ie: Q101 and Q201), and attached to 
>> two different footprints.
>> 
>> Cheers,
>> Jeff.
>> 
>>> On 22 Nov 2019, at 19:29, Brian >> <mailto:lotha...@gmail.com>> wrote:
>>> 
>>> From the peanut gallery:
>>> 
>>> Can someone tell me an example use-case for a single schematic symbol 
>>> corresponding to multiple board entities within a single project?
>>> 
>>> As perhaps a rather naïve PCB designer, it seems like mostly a bad idea to 
>>> me to have anything other than 1:1.
>>> 
>>> Thanks,
>>> -Brian Henning 
>>> 
>>>> On Nov 22, 2019, at 1:44 PM, Brian Piccioni >>> <mailto:br...@documenteddesigns.com>> wrote:
>>>> 
>>>> 
>>>> Wayne 
>>>>  
>>>> I thought I would weigh in as I am collaborating with Alexander.
>>>>  
>>>> If a designer manually re-annotates a board and schematics he would follow 
>>>> a number of steps:
>>>>  
>>>> Ensure the schematics, PCB, and netlist are coherent and without error 
>>>> (I.e. nothing in the schematics or PCB which is not in the other, netlist 
>>>> corresponds to schematic and PCB);
>>>> Manually edit each component on the board and keep a record of every 
>>>> change in a “change list”;
>>>> Manually edit the schematic in accordance with the “change list”;
>>>> Regenerate the netlist;
>>>> Update PCB from schematics;
>>>> Verify that the schematics and PCB are still coherent.
>>>>  
>>>> Manually editing the schematic would consist of going from component to 
>>>> component, looking up the component ref des in the “change list”, changing 
>>>> the ref des to the new value, and moving to the next component. The final 
>>>> step would only be necessary due to the near certainty that manual 
>>>> re-annotation would have introduced errors.
>>>>  
>>>> This is, more or less, what I do in my standalone application. 
>>>> Unfortunately, I also run roughshod over timestamps, etc.. Nonetheless, 
>>>> the application has been well received and appears to be used a fair bit.
>>>>  
>>>> If we were to write a demon (probably the wrong term) which essentially 
>>>> did the same steps, would that address your concerns?
>>>>  
>>>> Of course, we would use Kiway to accomplish the transfers but the approach 
>>>> would be pretty much identical to a manual re-annotation except far less 
>>>> likely to introduce errors.
>>>>  
>>>> If that would not work, can you please explain why? Perhaps if we 
>>>> understand why we can suggest solutions.
>>>>  
>>>> Brian
>>>>  
>>>> From: Wayne Stambaugh <mailto:stambau...@gmail.com>
>>>> Sent: November 22, 2019 12:03 PM
>>>> To: Alexander Shuklin <mailto:jasura...@gmail.com>
>>>> Cc: KiCad Developers <mailto:kicad-developers@lists.launchpad.net>
>>&g

Re: [Kicad-developers] Back annotate references from PCB

[Jeff Young]

Hi Brian,

Imagine you’re doing an audio amplifier.  Your main schematic sheet has 4 
subsheets: PSU, control logic, left channel and right channel.  Both left 
channel and right channel point to the same sub-page.  So there’s a single 
schematic symbol for each part in the left & right channel, which gets 
annotated as two different references (ie: Q101 and Q201), and attached to two 
different footprints.

Cheers,
Jeff.

> On 22 Nov 2019, at 19:29, Brian  wrote:
> 
> From the peanut gallery:
> 
> Can someone tell me an example use-case for a single schematic symbol 
> corresponding to multiple board entities within a single project?
> 
> As perhaps a rather naïve PCB designer, it seems like mostly a bad idea to me 
> to have anything other than 1:1.
> 
> Thanks,
> -Brian Henning 
> 
>> On Nov 22, 2019, at 1:44 PM, Brian Piccioni > > wrote:
>> 
>> 
>> Wayne 
>>  
>> I thought I would weigh in as I am collaborating with Alexander.
>>  
>> If a designer manually re-annotates a board and schematics he would follow a 
>> number of steps:
>>  
>> Ensure the schematics, PCB, and netlist are coherent and without error (I.e. 
>> nothing in the schematics or PCB which is not in the other, netlist 
>> corresponds to schematic and PCB);
>> Manually edit each component on the board and keep a record of every change 
>> in a “change list”;
>> Manually edit the schematic in accordance with the “change list”;
>> Regenerate the netlist;
>> Update PCB from schematics;
>> Verify that the schematics and PCB are still coherent.
>>  
>> Manually editing the schematic would consist of going from component to 
>> component, looking up the component ref des in the “change list”, changing 
>> the ref des to the new value, and moving to the next component. The final 
>> step would only be necessary due to the near certainty that manual 
>> re-annotation would have introduced errors.
>>  
>> This is, more or less, what I do in my standalone application. 
>> Unfortunately, I also run roughshod over timestamps, etc.. Nonetheless, the 
>> application has been well received and appears to be used a fair bit.
>>  
>> If we were to write a demon (probably the wrong term) which essentially did 
>> the same steps, would that address your concerns?
>>  
>> Of course, we would use Kiway to accomplish the transfers but the approach 
>> would be pretty much identical to a manual re-annotation except far less 
>> likely to introduce errors.
>>  
>> If that would not work, can you please explain why? Perhaps if we understand 
>> why we can suggest solutions.
>>  
>> Brian
>>  
>> From: Wayne Stambaugh 
>> Sent: November 22, 2019 12:03 PM
>> To: Alexander Shuklin 
>> Cc: KiCad Developers 
>> Subject: Re: [Kicad-developers] Back annotate references from PCB
>>  
>> I would prefer that you did ask questions rather than spending a lot of
>> development time on a solution that would not be accepted because it
>> breaks things.  This is not a trivial problem although it may appear
>> that way.  There are plenty of ways to implement back annotation that
>> will break things in unexpected ways.  There are a very few ways to not
>> break things.  This is why I'm telling you this.  If you don't care
>> about the schematic and the board references being synchronized, then
>> back-annotation isn't really necessary.  As soon as you attempt to
>> back-annotated the schematic from the board, all of the issues that I
>> have previously discussed come in to play and have to be addressed.
>>  
>> On 11/22/19 9:53 AM, Alexander Shuklin wrote:
>> > Excuse me for so much questions. There's plenty of ways how it can be
>> > done, and I'm quite new, maybe I don't see some simple way.
>> > I can back up data from pcbnew which is not up to date to schematics,
>> > after that I call update pcb dialog. Somebody will want to update pcb
>> > by references and after that I will have pcbnew old data which is not
>> > up to date either to schematics or layout anymore. I don't think there
>> > will be straight forward solution how to solve it.
>> > May I just open update pcb dialog and ask user to care about schematic
>> > and layout being up to date?
>> >
>> > On Fri, 22 Nov 2019 at 17:16, Wayne Stambaugh > > > wrote:
>> >> 
>> >> There is no need to create your own dialog.  Just call the update board
>> >> from schematic function before you back annotate.  You will have to make
>> >> a temporary copy of your board reference changes because updating from
>> >> the schematic will clobber any reference changes in the board.
>> >> 
>> >> On 11/22/19 9:13 AM, Alexander Shuklin wrote:
>> >>> Hi Wayne,
>> >>> 
>> >>> I don't want to start PCB update from eeschema straight away, because
>> >>> if you run back-annotation, you already changed some references in
>> >>> layout and you gonna lose it. And probably you can 

Re: [Kicad-developers] [PATCH] Eeschema: simulator: use dotted traces for current and phase.

[Jeff Young]

I think phase is always dotted in LTSpice, but current is solid.  You can chose 
the colour of any trace.

> On 21 Nov 2019, at 17:33, Ian McInerney  wrote:
> 
> This is probably introducing major feature creep, but it would be nice to 
> develop a dialog that allows setting the per-trace characteristics (such as 
> color, line type, line width, etc) that this could go in. Where we put the 
> accessors to it, I am not sure (it would be great if we could link it with 
> the legend fields). Then we can add in more configuration options there as we 
> implement them.
> 
> -Ian
> 
> On Thu, Nov 21, 2019 at 5:26 PM Wayne Stambaugh  > wrote:
> Hi Jonatan,
> 
> I just tested this and it seems to work as expected although I'm
> thinking it might be a good idea to make this a configuration option
> rather than the only behavior.  Users might not find this desirable.
> Anyone else have any thoughts on this?  For future reference, when you
> are going to make behavioral changes to KiCad, please ping the dev
> mailing list first for feedback.  I would have made the option
> suggestion before you began coding.
> 
> Cheers,
> 
> Wayne
> 
> On 11/19/19 11:30 AM, Jonatan Liljedahl wrote:
> > This patch makes it easier to visually keep apart traces for current
> > vs voltage and phase vs magnitude, by using dotted line style for
> > current and phase traces.
> > 
> > To get the dotted style drawn correctly, I had to switch from drawing
> > each trace line segment individually to creating an array and then
> > using DrawLines() on it, so that the whole trace is one continuous
> > line.
> > 
> > 
> > ___
> > 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] Building current master fails

[Jeff Young]

This will do it in one step:

find . -name *_lexer.h -delete

> On 20 Nov 2019, at 15:57, Adam Wolf  wrote:
> 
> Thanks for this! I have just been cleaning a lot.. :)
> 
> On Wed, Nov 20, 2019 at 9:16 AM Jeff Young  wrote:
>> 
>> I switch between 5.1 and master and back in the same tree.  You have to run 
>> the clean each time you go from 5.1 to master.
>> 
>> On 20 Nov 2019, at 14:34, Ian McInerney  wrote:
>> 
>> Thats correct, all those lexer files should now be in the build folder. I 
>> think that only the board file has had new keywords added, so it would be 
>> the only one that is different.
>> 
>> Ok, so there is probably another cause of the files appearing. Did you 
>> switch branches between master and 5.1 and back? 5.1 looks like it uses the 
>> old method of generating the lexer files, so it puts them in the source 
>> tree. Master was switched over in July to use the new way that puts them in 
>> the build folder.
>> 
>> -Ian
>> 
>> On Wed, Nov 20, 2019 at 11:51 AM Jonatan Liljedahl  
>> wrote:
>>> 
>>> Hi,
>>> 
>>> I see. So then I assume all these should also not exist?
>>> 
>>> $ ls include/*_lexer.h
>>> include/lib_table_lexer.h  include/netlist_lexer.h
>>> include/page_layout_reader_lexer.h include/pcb_lexer.h
>>> include/pcb_plot_params_lexer.h
>>> 
>>> Of these files, only pcb_lexer.h differed between include/ and 
>>> build/common/.
>>> 
>>> This is a fresh clone, I'm not sure how these files ended up in
>>> include/. I see that the files are not in the git file tree of either
>>> 5.1 or master branch. Maybe it happened when I built using
>>> kicad-mac-builder pointing it to my kicad source tree?
>>> 
>>> On Wed, Nov 20, 2019 at 12:09 PM Ian McInerney  
>>> wrote:
>>>> 
>>>> Jonatan,
>>>> 
>>>> The pcb_lexer.h in include/ shouldn't exist anymore. There was a 
>>>> switchover a few months ago in how that file was generated, and that 
>>>> change moved it into the build directory. As a consequence of that 
>>>> switchover, you need to clean out the stray files that existed from old 
>>>> build.
>>>> 
>>>> Try running this command in the repository (note, this command will remove 
>>>> any files you are ignoring in the git, so make sure you have everything 
>>>> you want to save copied before running):
>>>> 'git clean -fx'
>>>> 
>>>> Out of curiosity, is this an older build system that you are just 
>>>> updating, or is this a fresh clone since July?
>>>> 
>>>> -Ian
>>>> 
>>>> On Wed, Nov 20, 2019 at 10:46 AM Nick Østergaard  wrote:
>>>>> 
>>>>> It seems to build ok for linux on jenkins.
>>>>> 
>>>>> Maybe double chevk you are not in a merge state or something.  Also, 
>>>>> please state the has of the version you are trying to build.
>>>>> 
>>>>> ons. 20. nov. 2019 11.34 skrev Jonatan Liljedahl :
>>>>>> 
>>>>>> Hi, I'm trying to build the current master, cmake configured like this:
>>>>>> 
>>>>>> cmake 
>>>>>> -DNGSPICE_INCLUDE_DIR=/Users/lijon/Coding/kicad-mac-builder/build/ngspice-dest/include/
>>>>>> -DNGSPICE_LIBRARY=/Users/lijon/Coding/kicad-mac-builder/build/ngspice-dest/lib/libngspice.dylib
>>>>>> -DKICAD_USE_OCE=OFF -DKICAD_SCRIPTING=OFF
>>>>>> -DwxWidgets_CONFIG_EXECUTABLE=/Users/lijon/Coding/kicad-mac-builder/build/wxwidgets-dest/bin/wx-config
>>>>>> -DKICAD_BUILD_QA_TESTS=OFF -DCMAKE_OSX_DEPLOYMENT_TARGET=10.14 ../..
>>>>>> 
>>>>>> but it fails here:
>>>>>> 
>>>>>> [ 42%] Building CXX object
>>>>>> common/CMakeFiles/pcbcommon.dir/__/pcbnew/pcb_parser.cpp.o
>>>>>> /Users/lijon/Coding/kicad/pcbnew/pcb_parser.cpp:996:18: error: use of
>>>>>> undeclared identifier 'T_copper_finish'
>>>>>>case T_copper_finish:
>>>>>> ^
>>>>>> /Users/lijon/Coding/kicad/pcbnew/pcb_parser.cpp:1002:18: error: use of
>>>>>> undeclared identifier 'T_edge_plating'
>>>>>>case T_edge_plating:
>>>>>> ^
>>>>>> /Users/lijon/Coding/kicad/pcbnew/pcb_parser.cpp:1008:18: error: use of
>>

Re: [Kicad-developers] Building current master fails

[Jeff Young]

I switch between 5.1 and master and back in the same tree.  You have to run the 
clean each time you go from 5.1 to master.

> On 20 Nov 2019, at 14:34, Ian McInerney  wrote:
> 
> Thats correct, all those lexer files should now be in the build folder. I 
> think that only the board file has had new keywords added, so it would be the 
> only one that is different.
> 
> Ok, so there is probably another cause of the files appearing. Did you switch 
> branches between master and 5.1 and back? 5.1 looks like it uses the old 
> method of generating the lexer files, so it puts them in the source tree. 
> Master was switched over in July to use the new way that puts them in the 
> build folder.
> 
> -Ian
> 
> On Wed, Nov 20, 2019 at 11:51 AM Jonatan Liljedahl  > wrote:
> Hi,
> 
> I see. So then I assume all these should also not exist?
> 
> $ ls include/*_lexer.h
> include/lib_table_lexer.h  include/netlist_lexer.h
> include/page_layout_reader_lexer.h include/pcb_lexer.h
> include/pcb_plot_params_lexer.h
> 
> Of these files, only pcb_lexer.h differed between include/ and build/common/.
> 
> This is a fresh clone, I'm not sure how these files ended up in
> include/. I see that the files are not in the git file tree of either
> 5.1 or master branch. Maybe it happened when I built using
> kicad-mac-builder pointing it to my kicad source tree?
> 
> On Wed, Nov 20, 2019 at 12:09 PM Ian McInerney  > wrote:
> >
> > Jonatan,
> >
> > The pcb_lexer.h in include/ shouldn't exist anymore. There was a switchover 
> > a few months ago in how that file was generated, and that change moved it 
> > into the build directory. As a consequence of that switchover, you need to 
> > clean out the stray files that existed from old build.
> >
> > Try running this command in the repository (note, this command will remove 
> > any files you are ignoring in the git, so make sure you have everything you 
> > want to save copied before running):
> > 'git clean -fx'
> >
> > Out of curiosity, is this an older build system that you are just updating, 
> > or is this a fresh clone since July?
> >
> > -Ian
> >
> > On Wed, Nov 20, 2019 at 10:46 AM Nick Østergaard  > > wrote:
> >>
> >> It seems to build ok for linux on jenkins.
> >>
> >> Maybe double chevk you are not in a merge state or something.  Also, 
> >> please state the has of the version you are trying to build.
> >>
> >> ons. 20. nov. 2019 11.34 skrev Jonatan Liljedahl  >> >:
> >>>
> >>> Hi, I'm trying to build the current master, cmake configured like this:
> >>>
> >>> cmake 
> >>> -DNGSPICE_INCLUDE_DIR=/Users/lijon/Coding/kicad-mac-builder/build/ngspice-dest/include/
> >>> -DNGSPICE_LIBRARY=/Users/lijon/Coding/kicad-mac-builder/build/ngspice-dest/lib/libngspice.dylib
> >>> -DKICAD_USE_OCE=OFF -DKICAD_SCRIPTING=OFF
> >>> -DwxWidgets_CONFIG_EXECUTABLE=/Users/lijon/Coding/kicad-mac-builder/build/wxwidgets-dest/bin/wx-config
> >>> -DKICAD_BUILD_QA_TESTS=OFF -DCMAKE_OSX_DEPLOYMENT_TARGET=10.14 ../..
> >>>
> >>> but it fails here:
> >>>
> >>> [ 42%] Building CXX object
> >>> common/CMakeFiles/pcbcommon.dir/__/pcbnew/pcb_parser.cpp.o
> >>> /Users/lijon/Coding/kicad/pcbnew/pcb_parser.cpp:996:18: error: use of
> >>> undeclared identifier 'T_copper_finish'
> >>> case T_copper_finish:
> >>>  ^
> >>> /Users/lijon/Coding/kicad/pcbnew/pcb_parser.cpp:1002:18: error: use of
> >>> undeclared identifier 'T_edge_plating'
> >>> case T_edge_plating:
> >>>  ^
> >>> /Users/lijon/Coding/kicad/pcbnew/pcb_parser.cpp:1008:18: error: use of
> >>> undeclared identifier 'T_dielectric_constraints'
> >>> case T_dielectric_constraints:
> >>>  ^
> >>> /Users/lijon/Coding/kicad/pcbnew/pcb_parser.cpp:1014:18: error: use of
> >>> undeclared identifier 'T_edge_connector'; did you mean
> >>> 'T_zone_connect'?
> >>> case T_edge_connector:
> >>>  ^~~~
> >>>  T_zone_connect
> >>> /Users/lijon/Coding/kicad/include/pcb_lexer.h:232:9: note:
> >>> 'T_zone_connect' declared here
> >>> T_zone_connect,
> >>> ^
> >>> /Users/lijon/Coding/kicad/pcbnew/pcb_parser.cpp:1020:35: error: use of
> >>> undeclared identifier 'T_bevelled'
> >>> else if( token == T_bevelled )
> >>>   ^
> >>> /Users/lijon/Coding/kicad/pcbnew/pcb_parser.cpp:1026:18: error: use of
> >>> undeclared identifier 'T_castellated_pads'
> >>> case T_castellated_pads:
> >>>  ^
> >>> /Users/lijon/Coding/kicad/pcbnew/pcb_parser.cpp:1088:30: error: use of
> >>> undeclared identifier 'T_addsublayer'
> >>> if( token == T_addsublayer )
> >>>  ^
> >>> /Users/lijon/Coding/kicad/pcbnew/pcb_parser.cpp:1100:26: error: use of
> >>> undeclared identifier 'T_type'; did you mean 'T_top'?
> >>>   

Re: [Kicad-developers] [PATCH] Kicad: project manager: Do not reconstruct entire project tree when renaming file to different dir

[Jeff Young]

How bizarre.  Make you wonder how it worked on Mac and Windows.  (Hmmm… I 
wonder if GTK goes through wxFSW_EVENT_RENAME and Mac and Windows go through 
wxFSW_EVENT_DELETE and wxFSW_EVENT_CREATE?)

Your patch works on OSX except for one thing: it doesn’t get the selection 
right (selecting the next item in the moved-from location rather than keeping 
the moved item selected).

Cheers,
Jeff.


> On 16 Nov 2019, at 01:57, Ian McInerney  wrote:
> 
> Ok, so I dug into this some more and first of all, the changes that Jeff 
> pushed still didn't work on GTK.
> 
> The root cause of this doesn't appear to be our file system watcher, but was 
> instead the fact that the tree was being improperly updated. First of all, we 
> were renaming the old node with the new filename which was causing the 
> deletion routine in the rename fswatcher handler to never find it and remove 
> it. Second of all, we were adding the new file into the same directory as the 
> original file, so it was looking like it was never leaving.
> 
> I believe these two patches address the issues, and they work on my GTK box 
> for both a rename moving directories and a rename inside the same directory. 
> The first set just reverts the changes that Jeff made to the code to get it 
> back to the state it was originally, and the second is the actual new 
> changeset. @Jeff and @Mikolaj, if you could both test these changes on 
> Windows and OSX to see how they behave that would be good. If they work for 
> both of you I will push them.
> 
> -Ian
> 
> On Sat, Nov 16, 2019 at 1:00 AM Mikołaj Wielgus  <mailto:wielgusmiko...@gmail.com>> wrote:
> Jeff,
> 
> your new version appears to be working well on my computer on Windows.
> 
> Best regards,
> Mikołaj Wielgus
> 
> 
> On Sat, Nov 16, 2019 at 1:02 AM Jeff Young  <mailto:j...@rokeby.ie>> wrote:
> I pushed a smarter version of my original fix.  @Mikolaj & @Ian if you could 
> test it on Windows and GTK that would be great.
> 
> Cheers,
> Jeff.
> 
> 
>> On 15 Nov 2019, at 22:27, Ian McInerney > <mailto:ian.s.mciner...@ieee.org>> wrote:
>> 
>> Scratch my last. It is GTK with the problems. When I rename the file to a 
>> new directory with this patch, the tree never seems to update. I have to 
>> manually refresh it in order for the file to appear in the correct place.
>> 
>> -Ian
>> 
>> On Fri, Nov 15, 2019 at 10:21 PM Mikołaj Wielgus > <mailto:wielgusmiko...@gmail.com>> wrote:
>> Yes, I'm on Windows (the details are in the linked related bug report).
>> 
>> Sorry for the return value problem -- I failed to notice the warnings in 
>> console.
>> 
>> Best regards,
>> Mikołaj Wielgus
>> 
>> 
>> On Fri, Nov 15, 2019 at 11:07 PM Ian McInerney > <mailto:ian.s.mciner...@ieee.org>> wrote:
>> I'll give it a test on GTK once my build here finishes, but I don't think I 
>> have seen any issues with file watcher on GTK in the past.
>> 
>> -Ian
>> 
>> On Fri, Nov 15, 2019 at 10:03 PM Jeff Young > <mailto:j...@rokeby.ie>> wrote:
>> Hi Mikolaj,
>> 
>> The Mac compiler doesn’t like Rename() returning values when the return type 
>> is void.  However, after fixing that it works fine on Mac.
>> 
>> I remember however something about the file watcher not working on all 
>> platforms.  I thought the problem platform was Windows, though, so maybe I’m 
>> not remembering it correctly (as you’re on Windows, right?).
>> 
>> Can someone validate that this works on GTK?
>> 
>> Cheers,
>> Jeff.
>> 
>> 
>>> On 15 Nov 2019, at 21:05, Mikołaj Wielgus >> <mailto:wielgusmiko...@gmail.com>> wrote:
>>> 
>>> Hi,
>>> 
>>> Renaming file to a different directory causes the entire project tree to be 
>>> recreated, which causes all subdirectories to collapse, unexpectedly to the 
>>> user.
>>> 
>>> This patch solves the problem by deleting the original node after moving 
>>> the file. Then the file watcher raises an event whose handler constructs a 
>>> new node in the new location.
>>> 
>>> This issue comes from the fix to this bug:
>>> https://bugs.launchpad.net/kicad/+bug/1852431 
>>> <https://bugs.launchpad.net/kicad/+bug/1852431>
>>> 
>>> Best Regards,
>>> Mikołaj Wielgus
>>> <0001-Do-not-reconstruct-proj-tree-on-rename-to-diff-dir.patch>___
>>> Mailing list: https://launchpad.net/~kicad-developers 
>>> <https://launchpad.net/~kicad-developers>
>>>

Re: [Kicad-developers] [PATCH] Kicad: project manager: Do not reconstruct entire project tree when renaming file to different dir

[Jeff Young]

I pushed a smarter version of my original fix.  @Mikolaj & @Ian if you could 
test it on Windows and GTK that would be great.

Cheers,
Jeff.


> On 15 Nov 2019, at 22:27, Ian McInerney  wrote:
> 
> Scratch my last. It is GTK with the problems. When I rename the file to a new 
> directory with this patch, the tree never seems to update. I have to manually 
> refresh it in order for the file to appear in the correct place.
> 
> -Ian
> 
> On Fri, Nov 15, 2019 at 10:21 PM Mikołaj Wielgus  <mailto:wielgusmiko...@gmail.com>> wrote:
> Yes, I'm on Windows (the details are in the linked related bug report).
> 
> Sorry for the return value problem -- I failed to notice the warnings in 
> console.
> 
> Best regards,
> Mikołaj Wielgus
> 
> 
> On Fri, Nov 15, 2019 at 11:07 PM Ian McInerney  <mailto:ian.s.mciner...@ieee.org>> wrote:
> I'll give it a test on GTK once my build here finishes, but I don't think I 
> have seen any issues with file watcher on GTK in the past.
> 
> -Ian
> 
> On Fri, Nov 15, 2019 at 10:03 PM Jeff Young  <mailto:j...@rokeby.ie>> wrote:
> Hi Mikolaj,
> 
> The Mac compiler doesn’t like Rename() returning values when the return type 
> is void.  However, after fixing that it works fine on Mac.
> 
> I remember however something about the file watcher not working on all 
> platforms.  I thought the problem platform was Windows, though, so maybe I’m 
> not remembering it correctly (as you’re on Windows, right?).
> 
> Can someone validate that this works on GTK?
> 
> Cheers,
> Jeff.
> 
> 
>> On 15 Nov 2019, at 21:05, Mikołaj Wielgus > <mailto:wielgusmiko...@gmail.com>> wrote:
>> 
>> Hi,
>> 
>> Renaming file to a different directory causes the entire project tree to be 
>> recreated, which causes all subdirectories to collapse, unexpectedly to the 
>> user.
>> 
>> This patch solves the problem by deleting the original node after moving the 
>> file. Then the file watcher raises an event whose handler constructs a new 
>> node in the new location.
>> 
>> This issue comes from the fix to this bug:
>> https://bugs.launchpad.net/kicad/+bug/1852431 
>> <https://bugs.launchpad.net/kicad/+bug/1852431>
>> 
>> Best Regards,
>> Mikołaj Wielgus
>> <0001-Do-not-reconstruct-proj-tree-on-rename-to-diff-dir.patch>___
>> Mailing list: https://launchpad.net/~kicad-developers 
>> <https://launchpad.net/~kicad-developers>
>> Post to : kicad-developers@lists.launchpad.net 
>> <mailto:kicad-developers@lists.launchpad.net>
>> Unsubscribe : https://launchpad.net/~kicad-developers 
>> <https://launchpad.net/~kicad-developers>
>> More help   : https://help.launchpad.net/ListHelp 
>> <https://help.launchpad.net/ListHelp>
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> Post to : kicad-developers@lists.launchpad.net 
> <mailto:kicad-developers@lists.launchpad.net>
> Unsubscribe : https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> More help   : https://help.launchpad.net/ListHelp 
> <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] Project save as

[Jeff Young]

FWIW, the old generated files are not outdated — the paths in them are updated.

> On 11 Nov 2019, at 23:06, Eeli Kaikkonen  wrote:
> 
> 
> 
> ti 12. marrask. 2019 klo 0.02 Jon Evans (j...@craftyjon.com 
> ) kirjoitti:
> I question the value of creating this amount of complex UI around "save as".
> 
>  In that case I personally would prefer minimal functionality, copying only 
> the necessary project files. More likely than not the generated files aren't 
> needed or are outdated because of the name change (for example having the old 
> project name inside them). But if a large amount of files is renamed and 
> copied I would like to have control over it when it's done. Going though the 
> files afterwards is more difficult.
> 
> Anyways, renaming the necessary files of the project to form a new functional 
> project is the really needed feature and it's great to have it, with or 
> without complex additions.
> 
> Eeli Kaikkonen
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] Tab handling in text rendering and bbox calculation

[Jeff Young]

D’oh.  I was thinking our stroke font was mono-spaced, but then why would we 
have to look up widths in the width-table.  I think my brain worked better 
years ago, but perhaps it’s just nostalgia…. ;)

> On 12 Nov 2019, at 12:35, Johannes Sprigode  wrote:
> 
> If that is so then I rest my case.
> Apart from that a change in the anti-aliasing settings
> as suggested by Jeff didn't have any influence at all.
> 
> Cheers
> 
> On 13/11/19 1:26 am, Seth Hillbrand wrote:
>> On 2019-11-12 03:57, Johannes Sprigode wrote:
>>> Howdy guys,
>>> 
>>> hate to burst your bubble. The tab/space issue appears consistent,
>>> however the actual character alignment kind of sucks. Lower case a, b
>>> etc. are only part of the equation. The big guys still seem to have
>>> some sway.
>>> 
>>> Screen shot attached.
>>> 
>>> Cheers
>> 
>> The characters are not monospaced.  So, you shouldn't expect the line
>> of characters to align with the tab characters.
>> 
>> The tab character is meant to align with other tabs.
>> 
>> -Seth
>> 
>> Seth Hillbrand
>> KiCad Services Corporation
>> https://www.kipro-pcb.com
>> +1 530 302 5483 | +1 212 603 9372
>> 
>> ___
>> 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] Tab handling in text rendering and bbox calculation

[Jeff Young]

The artificial fattening of the middle of the character strokes suggests that 
Johannes has one of the subpixel anti-aliasing methods turned on.  While it 
doesn’t seem like that would have a cumulative effect of more than a single 
pixel, maybe it's somehow involved.

Johannes, does it change any if you set anti-aliasing to one of the 
supersampling methods?  (Preferences > Common > Accelerated Graphics)

> On 12 Nov 2019, at 11:57, Johannes Sprigode  wrote:
> 
> Howdy guys,
> 
> hate to burst your bubble. The tab/space issue appears consistent, however 
> the actual character alignment kind of sucks. Lower case a, b etc. are only 
> part of the equation. The big guys still seem to have some sway.
> 
> Screen shot attached.
> 
> Cheers
> 
> On 12/11/19 5:24 pm, Seth Hillbrand wrote:
>> On 2019-11-11 17:48, Andrew Lutsenko wrote:
>> 
>>> Hi Seth, Jeff,
>>> I see you have touched this code recently. I've noticed that tabs are 
>>> handled differently for bbox calculation resulting in slightly oversized 
>>> bbox.
>>>  
>>> When rendering tabs we count them as whatever width is needed to align to 
>>> multiple of 4 and  +1 additional space but when calculating bbox it is 
>>> align to 4 spaces + '?' width, which is a bit wider.
>>>  
>>> I attached a patch that fixes this particular issue to count tab as align 
>>> to 4 spaces + 1 space.
>>> But I think this is confusing in general, why do we still render another 
>>> space after aligning width to multiple of 4?
>>> Here is a picture of left-justified text in pcbnew. First line is 
>>> "ab", second "<4 spaces>b", third "<5 spaces>b".
>>>  
>>>  
>>> 
>>>  
>>> Regards,
>>> Andrew
>> 
>> Good catch.  I hadn't noticed that.  The intention (in the comments) was to 
>> align to the 4th column.  I pushed a fix as well as yours to the code.  
>> Thank you for your contribution to KiCad!
>> 
>> 
>> 
>> Best-
>> 
>> Seth
>> 
>> 
>> 
>>  
>> Seth Hillbrand
>> Lead Developer
>> +1-530-302-5483‬ 
>> Davis, CA
>> www.kipro-pcb.com i...@kipro-pcb.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

___
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] GitLab migration

[Jeff Young]

I’d definitely keep Fix Committed.

For Fix Released someone’s either going to try and find them from a plain-text 
search (which never worked for shit with Launchpad), or from a commit-message.  
The commit-message will just have the Launchpad number in it anyway, so they’re 
going to go to Launchpad for that.  

Still, plain-text searches would be nice (if they work better in GitLab), which 
might be a reason to migrate Fix Released bugs too….

> On 12 Nov 2019, at 10:32, Ian McInerney  wrote:
> 
> I think it makes sense to transfer the reports that are fix committed but not 
> fix released. That way we can have the entire v6 history attached to the new 
> milestone and more easily reference those reports in the future. Any that are 
> fix released we can leave on Launchpad.
> 
> -Ian
> 
> On Tue, Nov 12, 2019 at 9:04 AM Andrew Lutsenko  > wrote:
> I think there is value in having all the history in one place. Add to that 
> much more efficient search utilities and looking up history a year later will 
> be a lot easier if all of it is in gitlab and not split.
> 
> Just my 2c.
> 
> Andrew
> 
> On Tue, Nov 12, 2019 at 12:23 AM Maciej Suminski  > wrote:
> Hi Andrew,
> 
> I deliberately skipped the closed bugs, as I thought they do not carry
> much value, and they would still be available in the Launchpad tracker.
> If majority prefers to migrate the closed bugs, then there is nothing in
> the way.
> 
> Cheers,
> Orson
> 
> On 11/11/19 11:54 PM, Andrew Lutsenko wrote:
> > Is it possible to migrate closed bugs as well? I think gitlab search
> > indexing is much more useful, having history conserved there will likely
> > be handy.
> > 
> > On Mon, Nov 11, 2019 at 2:31 AM Maciej Suminski  > 
> > >> wrote:
> > 
> > Excellent, thanks for the verification! I have also checked a few other
> > reports that had original authors incorrectly assigned, so I believe the
> > bug has been fixed.
> > 
> > Cheers,
> > Orson
> > 
> > On 11/11/19 10:29 AM, Eeli Kaikkonen wrote:
> > > Now the example bug report ("Implicit 4-way junction" etc.) is
> > correctly
> > > attributed to "eelik".
> > >
> > > Eeli Kaikkonen
> > >
> > > su 10. marrask. 2019 klo 19.44 Maciej Suminski
> > (maciej.sumin...@cern.ch  
> > >
> > >  
> > >>)
> > kirjoitti:
> > >
> > > On 11/10/19 5:54 PM, Seth Hillbrand wrote:
> > > > On 2019-11-10 08:43, Seth Hillbrand wrote:
> > > >
> > > >> On 2019-11-10 08:33, Eeli Kaikkonen wrote:
> > > >>
> > > >>> OK. Would it be worth re-importing everything even for
> > this test
> > > database to avoid false impressions?
> > > >>>
> > > >>> Eeli Kaikkonen
> > > >>
> > > >> What false impression?  Is there a report that is listed as
> > being
> > > created by different people in launchpad vs. GitLab?
> > > >
> > > > Oops.  Disregard.  I see a broken report here:
> > > > https://gitlab.com/orsonmmz/kicad-bug-tracker/issues/7367 
> > 
> > > >
> > > > Looks like the Launchpad API doesn't handle users who have since
> > > deleted
> > > > their accounts nicely and the script is falling back on Fabien's
> > > > account, probably because his is index 0.
> > >
> > > Good catch, thanks! I think I have already found the bug, I
> > will let you
> > > know after the next run is finished.
> > >
> > > Cheers,
> > > Orson
> > >
> > > ___
> > > 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 
> > 

Re: [Kicad-developers] Project save as

[Jeff Young]

Limiting it to a dash is just because that’s all Kicad generates.  The user 
could indeed use anything.

So should we rename any file that starts with the old project name?  I did have 
a version that did that, but it seemed too aggressive to me.

> On 11 Nov 2019, at 20:56, Eeli Kaikkonen  wrote:
> 
> 
> 
> ma 11. marrask. 2019 klo 22.41 Jeff Young (j...@rokeby.ie 
> <mailto:j...@rokeby.ie>) kirjoitti:
> Yes, the current algorithm renames files that either match the project name 
> (with any extension), or start with the project name followed by a dash. 
> 
> Limiting the following character to dash seems arbitrary. Underscore is used 
> often, and why it should be limited at all?
> 
> Here's one more possible solution. The current file dialog is kept, but if 
> any generated or unknown files which begin with the project name are found, a 
> new dialog asks if the user wants to rename and copy them or not to copy them 
> at all, or maybe copy them as is.
> 
> On the other hand, what to do with other files which don't begin with the 
> project name? Should they be confirmed and copied (as is), too?
> 
> What about the backup files?
> 
> I can see two use cases: rename the project (replace the old one); and copy 
> the project to be a base for a new one. In the former case renaming and 
> keeping about everything could be desired. In the latter case all but the 
> basic project files would probably be ditched.
> 
> In the case of renaming I'm also interested in knowing how it affects version 
> control, for example git, if the project is a repository. That must be 
> tested, I think.
> 
> Eeli Kaikkonen
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

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

Re: [Kicad-developers] Project save as

[Jeff Young]

But even doing that is going to be more work, as they’re going to have to 
delete a whole pile of old files….

I have several old projects that I haven’t opened since the 4.0.x days.  I may 
want to move them, but regenerating the Gerbers wouldn’t necessarily generate 
the same files.  (It might if I was careful not to refill zones, but I’d still 
rather not find out, and if I knew less about the code I’d be even more 
reticent.)

> On 11 Nov 2019, at 20:42, Ian McInerney  wrote:
> 
> I agree, we should only be transferring and renaming the non-generated files 
> rather than trying to account for every possible file under the sun. If the 
> user wants the generated files, they can regenerate them from the new project.
> 
> -Ian
> 
> On Mon, 11 Nov 2019, 20:30 Jon Evans,  <mailto:j...@craftyjon.com>> wrote:
> In my opinion we should not rename any generated files.  This matches my 
> experience with other tools.
> 
> On Mon, Nov 11, 2019 at 3:28 PM Seth Hillbrand  <mailto:s...@kipro-pcb.com>> wrote:
> On 2019-11-11 11:42, Jeff Young wrote:
> 
> > A... I didn't notice that.  We are indeed failing to look for the 
> > Protel extensions.
> 
> Are we renaming generated files?  If we stick with base project files, 
> it's easy to explain where the cut-off is.  Once we go down into 
> generated files, this gets harder and harder especially as we start 
> implementing more exports (IPC-2581, D-365, XY files, etc) where we 
> don't control the extensions.
> 
> -Seth
> 
> 
> Seth Hillbrand
> KiCad Services Corporation
> https://www.kipro-pcb.com <https://www.kipro-pcb.com/>
> +1 530 302 5483 | +1 212 603 9372
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> Post to : kicad-developers@lists.launchpad.net 
> <mailto:kicad-developers@lists.launchpad.net>
> Unsubscribe : https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> More help   : https://help.launchpad.net/ListHelp 
> <https://help.launchpad.net/ListHelp>
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> Post to : kicad-developers@lists.launchpad.net 
> <mailto:kicad-developers@lists.launchpad.net>
> Unsubscribe : https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> More help   : https://help.launchpad.net/ListHelp 
> <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] Project save as

[Jeff Young]

Yes, the current algorithm renames files that either match the project name 
(with any extension), or start with the project name followed by a dash.  We 
don’t need to know the extension in either case.

This feels right to me, but I’m open to discussion.

Cheers,
Jeff.

> On 11 Nov 2019, at 20:29, Jon Evans  wrote:
> 
> In my opinion we should not rename any generated files.  This matches my 
> experience with other tools.
> 
> On Mon, Nov 11, 2019 at 3:28 PM Seth Hillbrand  <mailto:s...@kipro-pcb.com>> wrote:
> On 2019-11-11 11:42, Jeff Young wrote:
> 
> > A... I didn't notice that.  We are indeed failing to look for the 
> > Protel extensions.
> 
> Are we renaming generated files?  If we stick with base project files, 
> it's easy to explain where the cut-off is.  Once we go down into 
> generated files, this gets harder and harder especially as we start 
> implementing more exports (IPC-2581, D-365, XY files, etc) where we 
> don't control the extensions.
> 
> -Seth
> 
> 
> Seth Hillbrand
> KiCad Services Corporation
> https://www.kipro-pcb.com <https://www.kipro-pcb.com/>
> +1 530 302 5483 | +1 212 603 9372
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> Post to : kicad-developers@lists.launchpad.net 
> <mailto:kicad-developers@lists.launchpad.net>
> Unsubscribe : https://launchpad.net/~kicad-developers 
> <https://launchpad.net/~kicad-developers>
> More help   : https://help.launchpad.net/ListHelp 
> <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] Project save as

[Jeff Young]

A… I didn’t notice that.  We are indeed failing to look for the Protel 
extensions.

> On 11 Nov 2019, at 19:35, Eeli Kaikkonen  wrote:
> 
> ma 11. marrask. 2019 klo 20.39 Jeff Young (j...@rokeby.ie 
> <mailto:j...@rokeby.ie>) kirjoitti:
> I want to address the Gerber issue first.  In this case Eeli was expecting 
> the old name to get updated if it occurred anywhere in the filename.  My 
> expectation was that it would only get updated if the file name started with 
> the old name.
> 
>  
> It's not that. It's reasonable to expect that the project name is in the 
> beginning of the file name, especially with KiCad generated files. Try Save 
> As with the attached project. I plotted the gerbers with and without protel 
> extensions. When I Save As with name "test_saveas_plotted" or something like 
> that it renames only part of the files.
> 
> 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] Project save as

[Jeff Young]

Next for the folder or file question.

New project does indeed ask for the name of the project file and also asks if 
you want a directory auto-created.  I hate that, but I’ll admit it’s clearer 
than the Save As… case where you’re not sure which it’s asking for.

We have our own dialog for selecting folders for something. (3D paths?  
Import?)  While I can’t remember what, I do remember that it gets a lot of hate 
mail.

I’m open to suggestions.  (Including “just make it like New for now”.)

Cheers,
Jeff.


> On 11 Nov 2019, at 17:03, Eeli Kaikkonen  wrote:
> 
> More problems...
> 
> First, two complaints about error dialog. First, it's not resizable and the 
> file path text is shortened in the middle. Not good. Second, text can't be 
> copied (I think this is the case with all error dialogs? Very old and very 
> basic usability bug.)
> 
> 
> 
> The actual problem is that the file can't be copied for some reason. It's 
> inside the project folder in a project specific library. The project is 
> attached.
> 
> Eeli Kaikkonen
> 
> ma 11. marrask. 2019 klo 17.53 Eeli Kaikkonen (eeli.kaikko...@gmail.com 
> ) kirjoitti:
> I hope you don't mind I give some first impressions here. I can move these to 
> bug database if needed.
> 
> ___
> 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] Project save as

[Jeff Young]

I want to address the Gerber issue first.  In this case Eeli was expecting the 
old name to get updated if it occurred anywhere in the filename.  My 
expectation was that it would only get updated if the file name started with 
the old name.

Either is easy to implement, but I’d rather not have a preference.  Is one much 
more likely to be expected than the other?

Cheers,
Jeff.

> On 11 Nov 2019, at 17:03, Eeli Kaikkonen  wrote:
> 
> More problems...
> 
> First, two complaints about error dialog. First, it's not resizable and the 
> file path text is shortened in the middle. Not good. Second, text can't be 
> copied (I think this is the case with all error dialogs? Very old and very 
> basic usability bug.)
> 
> 
> 
> The actual problem is that the file can't be copied for some reason. It's 
> inside the project folder in a project specific library. The project is 
> attached.
> 
> Eeli Kaikkonen
> 
> ma 11. marrask. 2019 klo 17.53 Eeli Kaikkonen (eeli.kaikko...@gmail.com 
> ) kirjoitti:
> I hope you don't mind I give some first impressions here. I can move these to 
> bug database if needed.
> 
> ___
> 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] Test failures

[Jeff Young]

Hi Simon,

I’ve pushed changed which I hope will fix the spacing problem (but I never got 
the test environment working on my Mac so I’m not 100% sure).

Cheers,
Jeff.


> On 10 Nov 2019, at 09:28, Simon Richter  wrote:
> 
> Hi,
> 
> we seem to have picked up two test failure reports[1]:
> 
> [Info] - check KI_TEST::SexprIsListOfLength( (SEXPR::SEXPR&) s_list, 5 ) has 
> passed
> == [File] - 
> /var/lib/jenkins-agent/workspace/linux-kicad-head/src/qa/libs/sexpr/test_sexpr.cpp
> == [Line] - 101
> == [Context] Sexpr string conversion mismatch: got '(symbol 
>  (2 42.42 "substring") 1 3.14 "string")', expected '(symbol 
>(2 42.42 "substring") 1 3.14 "string")'
> 
> [Info] - check KI_TEST::SexprConvertsToString( *sexp, c.m_input ) has passed
> == [File] - 
> /var/lib/jenkins-agent/workspace/linux-kicad-head/src/qa/libs/sexpr/test_sexpr_parser.cpp
> == [Line] - 235
> [Info] - check KI_TEST::SexprConvertsToString( *sexp, c.m_input ) has passed
> == [File] - 
> /var/lib/jenkins-agent/workspace/linux-kicad-head/src/qa/libs/sexpr/test_sexpr_parser.cpp
> == [Line] - 235
> == [Context] empty list
> == [Context] simple list
> == [Context] nested list
> == [Context] Sexpr string conversion mismatch: got '(42 
>  (1 2))', expected '(42 
>(1 2))'
> 
> These aren't in the build log[2]:
> 
> Running tests...
> /usr/bin/ctest --force-new-ctest-process 
> Test project /var/lib/jenkins-agent/workspace/linux-kicad-head/build
>Start 1: qa_python
> 1/8 Test #1: qa_python    Passed0.47 sec
>Start 2: common_eeschema
> 2/8 Test #2: common_eeschema ..   Passed0.16 sec
>Start 3: common_pcbnew
> 3/8 Test #3: common_pcbnew    Passed0.17 sec
>Start 4: qa_common_gerbview
> 4/8 Test #4: qa_common_gerbview ...   Passed0.16 sec
>Start 5: pcbnew
> 5/8 Test #5: pcbnew ...   Passed0.15 sec
>Start 6: eeschema
> 6/8 Test #6: eeschema .   Passed0.15 sec
>Start 7: sexpr
> 7/8 Test #7: sexpr    Passed0.02 sec
>Start 8: kicad2step
> 8/8 Test #8: kicad2step ...   Passed0.02 sec
> 
> It seems the difference is in the number of indentations, so this is a
> minor issue, but I'm confused about errors in the report file and a clean
> log file, that is probably a bigger problem.
> 
>   Simon
> 
> [1] https://jenkins.simonrichter.eu/job/linux-kicad-head/3781/testReport/
> [2] https://jenkins.simonrichter.eu/job/linux-kicad-head/3781/console
> 
> ___
> 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] Project save as

[Jeff Young]

He he… I know our users.  I can be sure of a bug report even if I get it right. 
;)

> This is exactly why I never tackled this one.  Anytime your are trying
> to deal with complex relative path changes, the code gets rather messy.
> I doubt this will affect many users but you can be rest assured of a
> bug report if you get it wrong.
> 


___
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] Project save as

[Jeff Young]

Hi Wayne,

> On 9 Nov 2019, at 19:05, Wayne Stambaugh  wrote:
> 
> Hey Jeff,
> 
> On 11/9/2019 12:06 PM, Jeff Young wrote:
>> I’m working through the project Save As feature.
>> 
>> I currently have it renaming the top-level files, updating the symbol and 
>> footprint lib tables, updating paths in Gerber job files, and updating paths 
>> and filenames in the netlist.  
>> 
>> A couple of questions:
>> 
>> 1) The netlist I’m handling is a .net file which contains s-expressions.  
>> Are there other formats I need to worry about?  Do they also use .net, or 
>> some other extension(s)?
> 
> I don't think you need to copy files that are generated by KiCad such as
> netlist, gerber, and 3D model files.  These can all be regenerated from
> the new project.

Yeah, I thought about that (particularly in the case of a DRC report file).  I 
was sort of thinking it would be nice to keep them when we can, but not in the 
case of the DRC (as we can’t guarantee that there aren’t non-discriminate cases 
in the save-as algorithm, and we don’t want to certify a board as having passed 
DRC in that case).

> 
>> 
>> 2) Mention was made of updating sheet paths in .sch files.  However, those 
>> never refer to the top-level schematic, do they?  If other sheet paths are 
>> absolute then we shouldn’t update them, and if they’re relative then we 
>> don’t need to update them.  Or am I missing something?
> 
> Relative paths will need to be updated if they are not contained in the
> current project path and the new saved project path is at a different
> branch depth in the path tree.  Example: a sheet schematic path is
> ../some_other_path/some_other.sch and the project is saved to
> ../one_node_deeper/project_saved_as/, the sheet schematic path would
> have to be adjusted to ../../some_other_path/some_other.sch in order for
> the schematic to load correctly.  This is the primary reason this
> feature does not exist yet.  It's not as trivial as it would seem to
> implement unless you don't care about breaking the saved as project.

I really don’t think we want to touch paths with “..” in them.  How do we know 
the user isn’t cloning a whole tree, and that the target of the relative path 
is also getting saved-as and they want to keep the relative path the same?  We 
won’t generate that path automatically, so the user “owns” it.

Cheers,
Jeff.

> 
>> 
>> 3) What about legacy schematic and/or board files?  Any paths in those?
> 
> Any relative 3D model paths suffer from the same problem described
> about.  I'm not sure the 3D path code allows for relative 3D model paths.
> 
> That's all I can think of at the moment but that doesn't mean there are
> not other issues that I've missed.
> 
>> 
>> Thanks,
>> Jeff.
>> ___
>> 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] Project save as

[Jeff Young]

I’m working through the project Save As feature.

I currently have it renaming the top-level files, updating the symbol and 
footprint lib tables, updating paths in Gerber job files, and updating paths 
and filenames in the netlist.  

A couple of questions:

1) The netlist I’m handling is a .net file which contains s-expressions.  Are 
there other formats I need to worry about?  Do they also use .net, or some 
other extension(s)?

2) Mention was made of updating sheet paths in .sch files.  However, those 
never refer to the top-level schematic, do they?  If other sheet paths are 
absolute then we shouldn’t update them, and if they’re relative then we don’t 
need to update them.  Or am I missing something?

3) What about legacy schematic and/or board files?  Any paths in those?

Thanks,
Jeff.
___
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] New lead developer announcement

[Jeff Young]

Woot!

Congrats, Ian!

Cheers,
Jeff.


> On 7 Nov 2019, at 20:14, Wayne Stambaugh  wrote:
> 
> I am happy to announce that the KiCad project now has a new member of
> the lead development team.  Ian McInerney has accepted an invitation to
> become a member of the lead development team.  Ian's contributions have
> earned him this privilege and we are grateful for his efforts.  Please
> join me in congratulating Ian and welcoming in his new role.
> 
> 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