Re: [Kicad-developers] Git noob question

[Tiger12506]

I'm not a kicad dev, just an avid reader of the list, but I am pretty 
fluent in git.
Here are some aliases that you might find useful (that go in your 
~/.gitconfig)


[alias]
    co = checkout
    ci = commit
    st = status
    br = branch
    hist = log --all --abbrev-commit --graph --date=short 
--pretty=format:\"%h %C(yellow)%aN %C(green)| %C(cyan)%d%Creset%s\"
    histd = log --all --abbrev-commit --graph --date=short 
--pretty=format:\"%h %C(green)%ad %C(yellow)%aN%Creset | 
%C(cyan)%d%Creset%s\"
    ll = log --all --stat --abbrev-commit --graph 
--pretty=format:\"%C(green)%h %aN | %C(yellow)%d%C(green)%s\"

    type = cat-file -t
    dump = cat-file -p
    d = whatchanged -1 -p
    del = !git rm $(git ls-files --deleted)
    dc = diff --cached
    wd = diff --word-diff
    cw = diff --color-words
    b = blame -w


I tend to use `git hist` and `git st` all the time. So that I can always 
see what's going on, I never use git pull, I always use git fetch 
instead. That seems to be in-line with what Wayne expects, since he says 
to rebase your changes. git pull would do a fetch and merge together, 
but you want to fetch and rebase -- you can set your .gitconfig to do 
the fetch and rebase, but I think it's easier to follow along with 
what's going on if you do the fetch separately and check the tree each 
time with git hist.



___
Mailing list: https://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 noob question

[Wayne Stambaugh]

This depends on which remote your local repo is linked to.  I keep two
completely separate repos.  One directly linked to the main kicad repo.
I use this one for patch merges and very minor changes.  The result of
`git remote -v` for this repo looks like this:

origin  git+ssh://stambau...@git.launchpad.net/kicad (fetch)
origin  git+ssh://stambau...@git.launchpad.net/kicad (push)

From this repo I always push from the local master branch directly to
the main kicad repo on launchpad using `git push`

The output of `git remote -v of my personal development repo looks like
this:

origin
git+ssh://stambau...@git.launchpad.net/~stambaughw/kicad/+git/kicad-dev
(fetch)
origin
git+ssh://stambau...@git.launchpad.net/~stambaughw/kicad/+git/kicad-dev
(push)
upstreamgit+ssh://stambau...@git.launchpad.net/kicad (fetch)
upstreamgit+ssh://stambau...@git.launchpad.net/kicad (push)

When I do a `git push` from local master, it gets pushed to my public
repo on launchpad[1] rather than the main kicad repo.  If I want to push
to the main kicad repo, I do a `git push upstream master`.  If I want to
sync this repo with the main kicad repo I run `git pull upstream
master`.  I can add any number of remotes to this repo so I can pull
other developers work for testing and comment without creating yet
another repo.  This repo will often have two or three other remotes.
This is what I will do to test your v6 changes.

[1]: https://code.launchpad.net/~stambaughw/kicad/+git/kicad-dev

On 3/2/2018 4:16 PM, Jeff Young wrote:
> OK, I followed Seth’s recipe so I’m now “right-side-up”.  (5.0 on
> master; 6.0 on a branch)
> 
> But I still don’t want to do a general push (as that will copy all my
> branches), right?
> 
> So I do a:
> 
> git push origin master
> 
> right?
> 
> Next question, when it asks for my launchpad username, what’s it looking
> for?  (My “launchpad id” is “jeyjey”, but when I change my password it
> sends me to Ubuntu.One and suggests “j...@rokeby.ie
> ”.  Neither one seems to work from git.)
> 
> Thanks,
> Jeff
> 
> 
>> On 2 Mar 2018, at 21:09, Wayne Stambaugh > > wrote:
>>
>> Jeff,
>>
>> Please remember no v6 stuff until the stable 5 version is released and
>> branched.  If you muck it up, I can always overwrite it with the last
>> valid commit.
>>
>> Cheers,
>>
>> Wayne
>>
>> On 03/02/2018 04:03 PM, Seth Hillbrand wrote:
>>> Jeff-
>>> As a fellow refuge from centralized VCSs, I sympathize.  It took me a
>>> while to learn to love git branch but it is your friend.
>>> Here's a quick way to get into the layout Wayne was recommending:
>>> git checkout master (you are now in your branch that has all the V6
>>> stuff)
>>> git checkout -b v6_updates (you have now created and checked out a
>>> new branch with your V6 mods)
>>> git checkout master (back to master again)
>>> git reset --hard upstream/master (This discards all of your changes
>>> to the master branch and puts you back in line with launchpad's master)
>>> After this, you will have a v6_updates branch with your V6 changes
>>> and a clean master branch.  When you are ready to create a new
>>> feature, you just `git checkout -b new_feature_branch` and go.
>>> -S
>>> 2018-03-02 12:48 GMT-08:00 Jon Evans >>  >:
>>>    (to make this last point easier, you can configure git to
>>>    automatically rebase when you do `git pull` :
>>>    https://stevenharman.net/git-pull-with-automatic-rebase
>>>     )
>>>    On Fri, Mar 2, 2018 at 3:46 PM, Wayne Stambaugh
>>>    
>>> > wrote:
>>>    Jeff,
>>>    On 03/02/2018 03:28 PM, Jeff Young wrote:
>>>    Before I go and make a hash of everything, can someone
>>>    please validate the following.
>>>    I have a bunch of 6.0 work on my master.
>>>    Making changes to master is risky unless you doing a simple bug
>>>    fix but even then I work in a separate branch then merge into
>>>    master before I push.  You should be using a new branch at a
>>>    minimum.  Better yet, a branch per feature that you keep up to
>>>    date with the upstream master so they merge cleanly.
>>>    I have a 5.0stable branch that I use for 5.0.
>>>    If I want to push changes for RC2, I’d do:
>>>    git push origin 5.0stable:master
>>>    As long as origin is linked to the main launchpad repo, you can
>>>    just do a `git push`.  If it's not linked to master than you run
>>>    `git push repo_name master` where repo name is what ever you
>>>    named with the `git remote` command.  You can check your remote
>>>    links using `git remote -v`.  Make sure you rebase you changes
>>>    against upstream so we don't have all of you branch/merge info
>>>    

Re: [Kicad-developers] Git noob question

[Jeff Young]

OK, I followed Seth’s recipe so I’m now “right-side-up”.  (5.0 on master; 6.0 
on a branch)

But I still don’t want to do a general push (as that will copy all my 
branches), right?

So I do a:

git push origin master

right?

Next question, when it asks for my launchpad username, what’s it looking for?  
(My “launchpad id” is “jeyjey”, but when I change my password it sends me to 
Ubuntu.One and suggests “j...@rokeby.ie ”.  Neither one 
seems to work from git.)

Thanks,
Jeff


> On 2 Mar 2018, at 21:09, Wayne Stambaugh  wrote:
> 
> Jeff,
> 
> Please remember no v6 stuff until the stable 5 version is released and 
> branched.  If you muck it up, I can always overwrite it with the last valid 
> commit.
> 
> Cheers,
> 
> Wayne
> 
> On 03/02/2018 04:03 PM, Seth Hillbrand wrote:
>> Jeff-
>> As a fellow refuge from centralized VCSs, I sympathize.  It took me a while 
>> to learn to love git branch but it is your friend.
>> Here's a quick way to get into the layout Wayne was recommending:
>> git checkout master (you are now in your branch that has all the V6 stuff)
>> git checkout -b v6_updates (you have now created and checked out a new 
>> branch with your V6 mods)
>> git checkout master (back to master again)
>> git reset --hard upstream/master (This discards all of your changes to the 
>> master branch and puts you back in line with launchpad's master)
>> After this, you will have a v6_updates branch with your V6 changes and a 
>> clean master branch.  When you are ready to create a new feature, you just 
>> `git checkout -b new_feature_branch` and go.
>> -S
>> 2018-03-02 12:48 GMT-08:00 Jon Evans > >:
>>(to make this last point easier, you can configure git to
>>automatically rebase when you do `git pull` :
>>https://stevenharman.net/git-pull-with-automatic-rebase
>> )
>>On Fri, Mar 2, 2018 at 3:46 PM, Wayne Stambaugh
>>> wrote:
>>Jeff,
>>On 03/02/2018 03:28 PM, Jeff Young wrote:
>>Before I go and make a hash of everything, can someone
>>please validate the following.
>>I have a bunch of 6.0 work on my master.
>>Making changes to master is risky unless you doing a simple bug
>>fix but even then I work in a separate branch then merge into
>>master before I push.  You should be using a new branch at a
>>minimum.  Better yet, a branch per feature that you keep up to
>>date with the upstream master so they merge cleanly.
>>I have a 5.0stable branch that I use for 5.0.
>>If I want to push changes for RC2, I’d do:
>>git push origin 5.0stable:master
>>As long as origin is linked to the main launchpad repo, you can
>>just do a `git push`.  If it's not linked to master than you run
>>`git push repo_name master` where repo name is what ever you
>>named with the `git remote` command.  You can check your remote
>>links using `git remote -v`.  Make sure you rebase you changes
>>against upstream so we don't have all of you branch/merge info
>>in the main repo.
>>Wayne
>>Is that right?
>>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
>>
>> ___
>> 

Re: [Kicad-developers] Git noob question

[Wayne Stambaugh]

Jeff,

Please remember no v6 stuff until the stable 5 version is released and 
branched.  If you muck it up, I can always overwrite it with the last 
valid commit.


Cheers,

Wayne

On 03/02/2018 04:03 PM, Seth Hillbrand wrote:

Jeff-

As a fellow refuge from centralized VCSs, I sympathize.  It took me a 
while to learn to love git branch but it is your friend.


Here's a quick way to get into the layout Wayne was recommending:

git checkout master (you are now in your branch that has all the V6 stuff)
git checkout -b v6_updates (you have now created and checked out a new 
branch with your V6 mods)

git checkout master (back to master again)
git reset --hard upstream/master (This discards all of your changes to 
the master branch and puts you back in line with launchpad's master)


After this, you will have a v6_updates branch with your V6 changes and a 
clean master branch.  When you are ready to create a new feature, you 
just `git checkout -b new_feature_branch` and go.


-S

2018-03-02 12:48 GMT-08:00 Jon Evans >:


(to make this last point easier, you can configure git to
automatically rebase when you do `git pull` :
https://stevenharman.net/git-pull-with-automatic-rebase
 )

On Fri, Mar 2, 2018 at 3:46 PM, Wayne Stambaugh
> wrote:

Jeff,

On 03/02/2018 03:28 PM, Jeff Young wrote:

Before I go and make a hash of everything, can someone
please validate the following.

I have a bunch of 6.0 work on my master.


Making changes to master is risky unless you doing a simple bug
fix but even then I work in a separate branch then merge into
master before I push.  You should be using a new branch at a
minimum.  Better yet, a branch per feature that you keep up to
date with the upstream master so they merge cleanly.


I have a 5.0stable branch that I use for 5.0.

If I want to push changes for RC2, I’d do:

git push origin 5.0stable:master


As long as origin is linked to the main launchpad repo, you can
just do a `git push`.  If it's not linked to master than you run
`git push repo_name master` where repo name is what ever you
named with the `git remote` command.  You can check your remote
links using `git remote -v`.  Make sure you rebase you changes
against upstream so we don't have all of you branch/merge info
in the main repo.

Wayne


Is that right?

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





___
Mailing list: https://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] Git noob question

[Seth Hillbrand]

Jeff-

As a fellow refuge from centralized VCSs, I sympathize.  It took me a while
to learn to love git branch but it is your friend.

Here's a quick way to get into the layout Wayne was recommending:

git checkout master (you are now in your branch that has all the V6 stuff)
git checkout -b v6_updates (you have now created and checked out a new
branch with your V6 mods)
git checkout master (back to master again)
git reset --hard upstream/master (This discards all of your changes to the
master branch and puts you back in line with launchpad's master)

After this, you will have a v6_updates branch with your V6 changes and a
clean master branch.  When you are ready to create a new feature, you just
`git checkout -b new_feature_branch` and go.

-S

2018-03-02 12:48 GMT-08:00 Jon Evans :

> (to make this last point easier, you can configure git to automatically
> rebase when you do `git pull` : https://stevenharman.net/
> git-pull-with-automatic-rebase )
>
> On Fri, Mar 2, 2018 at 3:46 PM, Wayne Stambaugh 
> wrote:
>
>> Jeff,
>>
>> On 03/02/2018 03:28 PM, Jeff Young wrote:
>>
>>> Before I go and make a hash of everything, can someone please validate
>>> the following.
>>>
>>> I have a bunch of 6.0 work on my master.
>>>
>>
>> Making changes to master is risky unless you doing a simple bug fix but
>> even then I work in a separate branch then merge into master before I
>> push.  You should be using a new branch at a minimum.  Better yet, a branch
>> per feature that you keep up to date with the upstream master so they merge
>> cleanly.
>>
>>
>>> I have a 5.0stable branch that I use for 5.0.
>>>
>>> If I want to push changes for RC2, I’d do:
>>>
>>> git push origin 5.0stable:master
>>>
>>
>> As long as origin is linked to the main launchpad repo, you can just do a
>> `git push`.  If it's not linked to master than you run `git push repo_name
>> master` where repo name is what ever you named with the `git remote`
>> command.  You can check your remote links using `git remote -v`.  Make sure
>> you rebase you changes against upstream so we don't have all of you
>> branch/merge info in the main repo.
>>
>> Wayne
>>
>>
>>> Is that right?
>>>
>>> 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
>
>
___
Mailing list: https://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 noob question

[Jon Evans]

(to make this last point easier, you can configure git to automatically
rebase when you do `git pull` :
https://stevenharman.net/git-pull-with-automatic-rebase )

On Fri, Mar 2, 2018 at 3:46 PM, Wayne Stambaugh 
wrote:

> Jeff,
>
> On 03/02/2018 03:28 PM, Jeff Young wrote:
>
>> Before I go and make a hash of everything, can someone please validate
>> the following.
>>
>> I have a bunch of 6.0 work on my master.
>>
>
> Making changes to master is risky unless you doing a simple bug fix but
> even then I work in a separate branch then merge into master before I
> push.  You should be using a new branch at a minimum.  Better yet, a branch
> per feature that you keep up to date with the upstream master so they merge
> cleanly.
>
>
>> I have a 5.0stable branch that I use for 5.0.
>>
>> If I want to push changes for RC2, I’d do:
>>
>> git push origin 5.0stable:master
>>
>
> As long as origin is linked to the main launchpad repo, you can just do a
> `git push`.  If it's not linked to master than you run `git push repo_name
> master` where repo name is what ever you named with the `git remote`
> command.  You can check your remote links using `git remote -v`.  Make sure
> you rebase you changes against upstream so we don't have all of you
> branch/merge info in the main repo.
>
> Wayne
>
>
>> Is that right?
>>
>> 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

Re: [Kicad-developers] Git noob question

[Wayne Stambaugh]

Jeff,

On 03/02/2018 03:28 PM, Jeff Young wrote:
Before I go and make a hash of everything, can someone please validate 
the following.


I have a bunch of 6.0 work on my master.


Making changes to master is risky unless you doing a simple bug fix but 
even then I work in a separate branch then merge into master before I 
push.  You should be using a new branch at a minimum.  Better yet, a 
branch per feature that you keep up to date with the upstream master so 
they merge cleanly.




I have a 5.0stable branch that I use for 5.0.

If I want to push changes for RC2, I’d do:

git push origin 5.0stable:master


As long as origin is linked to the main launchpad repo, you can just do 
a `git push`.  If it's not linked to master than you run `git push 
repo_name master` where repo name is what ever you named with the `git 
remote` command.  You can check your remote links using `git remote -v`. 
 Make sure you rebase you changes against upstream so we don't have all 
of you branch/merge info in the main repo.


Wayne



Is that right?

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

Re: [Kicad-developers] [PATCH] Rework footprint selection filtering to improve behavior

[Andy Peters]

> On Mar 2, 2018, at 10:28 AM, Andrzej Wolski  wrote:
> 
> Jon,
> 
> I probably didn't express myself clearly. What I mean is a situation when 
> *only* enabled layer if F.Paste and then you disable "Pads Front". Now 
> nothing is visible on the board, but footprints are still selectable.
> 
> In other words, when no single item belonging to footprint is visible, 
> footprints should not be selectable.
> 
> Do you still disagree with me?

I agree with Andrzej. This is the crux of my bug report.

But I understand what Jon is saying, and it doesn’t contradict. If the _pads_ 
(for example) are invisible, but say the silkscreen is visible, then the 
footprint _should_ be selectable.

That, I think, is the difference between layer visibility and item visibility. 
All of the layers could be visible, but if I disable Footprints Front, then 
everything associated with all top-layer footprints vanishes and none of the 
footprints can be selected. That’s the proper operation.

The converse of that is if I leave Footprints Front visibility enabled, and 
then I go and disable all of the layers associated with front footprints, like 
I did in my bug report case (disable all layers except Cmts.User), I am still 
able to select all of the invisible footprints. That’s not correct (IMHO).

-a


> 
> Andrzej
> 
> W dniu 2018-03-02 o 15:42, Jon Evans pisze:
>> Hi Andrzej,
>> 
>> This was my intention, which is why I said I was prepared for other people 
>> to have other opinions :-)
>> 
>> I think that you should still be able to select footprints even if the 
>> "front pads" is hidden from layers like the paste layer, *unless* you are in 
>> high contrast mode.
>> 
>> -Jon
>> 
>> On Fri, Mar 2, 2018 at 3:53 AM, Andrzej Wolski > > wrote:
>> I've tried this patch, and there is a small issue: if you have only eg front 
>> paste layer enabled and front pads are hidden, footprint is still selectable.
>> 
>> Andrzej
>> 
>> 
>> W dniu 2018-02-27 o 04:11, Jon Evans pisze:
>>> This patch changes the selection logic for footprints to fix a reported 
>>> issue[1] and to make the behavior more logical to me.
>>> 
>>> I know that correct selection behavior is something of a personal 
>>> preference, so I'm ready to be flamed :-)
>>> 
>>> The new behavior:
>>> 
>>> A footprint may be selected if:
>>> 1) The corresponding "Footprints" switch is on in the Items tab, AND
>>> 2) One or more of the layers that the footprint draws on is visible
>>> 
>>> This means that if all of the layers are turned off, footprints are not 
>>> selectable (fixes the bug), but it also means that now footprints can be 
>>> selected if any draw layers are visible (for example, if you have only 
>>> F.Mask enabled, you can select a footprint that has solder mask and is on 
>>> the front layer).
>>> 
>>> Before anyone complains, this is only if high-contrast mode is turned OFF.  
>>> When it is on, you can still only select items that *only* exist on that 
>>> layer (to make moving silkscreen around easier, for example)
>>> 
>>> Even though this adds some more for-loops to selection filtering, I have 
>>> not noticed any performance hits on some selection of large boards that I 
>>> tested.  More testing is welcome.
>>> 
>>> [1] https://bugs.launchpad.net/kicad/+bug/1751960 
>>> 
>>> 
>>> -Jon
>>> 

___
Mailing list: https://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] Git noob question

[Jeff Young]

Before I go and make a hash of everything, can someone please validate the 
following.

I have a bunch of 6.0 work on my master.

I have a 5.0stable branch that I use for 5.0.

If I want to push changes for RC2, I’d do:

git push origin 5.0stable:master

Is that right?

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] Mac HighDPI performance

[Bernhard Stegmaier]

Hi,

to be honest, I don’t really know what this is about.

@Andrey:
You looked for a very complex (foreign) project (Chris mainboard?) to prove 
that eeschema is slow on Mac?
Well, we know that and we told you already some weeks/months ago why it is like 
it is (if memory serves me right).

Or, do you have an own project that is so ridiculously slow, that you can’t 
work with it?
If so, please provide it so that we can analyse why this specific project 
behaves like that.
If you can’t or don’t want to provide it we could tell you how to do some 
performance measurements so that we might see something.

Obviously, there are a number of Mac users here and also over at the KiCad 
forum who might also be happy to get some more performance here and there, but 
who are in general reasonably able to work on their projects (including myself, 
on a 2012 Retina MacBook with only an i5).


Regards,
Bernhard

> On 2. Mar 2018, at 17:59, Andy Peters  wrote:
> 
> 
> 
>> On Mar 1, 2018, at 8:53 PM, Seth Hillbrand  wrote:
>> 
>> Andrey-
>> 
>> I'm moving this to a new thread so that we don't conflate the OpenMP 
>> discussion with this.
>> 
>> Can you test running Kicad with the "Open in Low Resolution" mode enabled?  
>> You can activate this by choosing "Get Info" on the main KiCad application 
>> and checking the option that says "Open in Low Resolution".  You may need to 
>> do the same for the other applications (Eeschema, pcbnew, etc) as well.
> 
> testing on my 2017” touch-bar MBP … 
> 
> Good g-d, low-res mode looks fuzzy and weird!
> 
> I don’t notice any specific differences in EESchema performance. Maybe my 
> schematic isn’t busy enough? I’m a fan of using more smaller sheets with less 
> info on each than one big sheet with everything.
> 
> I know, anecdote is not evidence.
> 
> -a
> 
> 
>> 
>> -Seth
>> 
>> ​​2018-03-01 18:09 GMT-08:00 Andrey Kuznetsov :
>> Hi,
>> 
>> So for now I've had a chance to test the motherboard project on my Retina 
>> macbook display.
>> eeschema: horrible zoom, feels like elastic band zoom and I have all scroll 
>> wheel accelerations and similar disabled, zoom response is super laggy, 
>> cannot work like this, will need to make schematics on windows.
>> pcbnew by order of slowness:
>> legacy - pretty slow, zoom lag is major, boo boo
>> modern (fallback) - decent, but the lag can be felt, zoom lag is minor
>> modern (accelerated) - almost cannot feel the lag, very nice, nice zoom 
>> responsiveness
>> 
>> I'll report tomorrow on 5K LG display.
>> ​
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


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

Re: [Kicad-developers] [PATCH] Rework footprint selection filtering to improve behavior

[Jon Evans]

No, I agree with you in that case, that sounds like a bug in my patch and
I'll check it out this weekend when I can get back to coding.

Thanks,
Jon

On Fri, Mar 2, 2018 at 12:28 PM, Andrzej Wolski 
wrote:

> Jon,
>
> I probably didn't express myself clearly. What I mean is a situation when
> *only* enabled layer if F.Paste and then you disable "Pads Front". Now
> nothing is visible on the board, but footprints are still selectable.
>
> In other words, when no single item belonging to footprint is visible,
> footprints should not be selectable.
>
> Do you still disagree with me?
>
> Andrzej
>
> W dniu 2018-03-02 o 15:42, Jon Evans pisze:
>
> Hi Andrzej,
>
> This was my intention, which is why I said I was prepared for other people
> to have other opinions :-)
>
> I think that you should still be able to select footprints even if the
> "front pads" is hidden from layers like the paste layer, *unless* you are
> in high contrast mode.
>
> -Jon
>
> On Fri, Mar 2, 2018 at 3:53 AM, Andrzej Wolski 
> wrote:
>
>> I've tried this patch, and there is a small issue: if you have only eg
>> front paste layer enabled and front pads are hidden, footprint is still
>> selectable.
>>
>> Andrzej
>>
>>
>> W dniu 2018-02-27 o 04:11, Jon Evans pisze:
>>
>> This patch changes the selection logic for footprints to fix a reported
>> issue[1] and to make the behavior more logical to me.
>>
>> I know that correct selection behavior is something of a personal
>> preference, so I'm ready to be flamed :-)
>>
>> The new behavior:
>>
>> A footprint may be selected if:
>> 1) The corresponding "Footprints" switch is on in the Items tab, AND
>> 2) One or more of the layers that the footprint draws on is visible
>>
>> This means that if all of the layers are turned off, footprints are not
>> selectable (fixes the bug), but it also means that now footprints can be
>> selected if any draw layers are visible (for example, if you have only
>> F.Mask enabled, you can select a footprint that has solder mask and is on
>> the front layer).
>>
>> Before anyone complains, this is only if high-contrast mode is turned
>> OFF.  When it is on, you can still only select items that *only* exist on
>> that layer (to make moving silkscreen around easier, for example)
>>
>> Even though this adds some more for-loops to selection filtering, I have
>> not noticed any performance hits on some selection of large boards that I
>> tested.  More testing is welcome.
>>
>> [1] https://bugs.launchpad.net/kicad/+bug/1751960
>>
>> -Jon
>>
>>
>> ___
>> Mailing list: https://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] [PATCH] Rework footprint selection filtering to improve behavior

[Andrzej Wolski]

Jon,

I probably didn't express myself clearly. What I mean is a situation 
when *only* enabled layer if F.Paste and then you disable "Pads Front". 
Now nothing is visible on the board, but footprints are still selectable.


In other words, when no single item belonging to footprint is visible, 
footprints should not be selectable.


Do you still disagree with me?

Andrzej

W dniu 2018-03-02 o 15:42, Jon Evans pisze:

Hi Andrzej,

This was my intention, which is why I said I was prepared for other 
people to have other opinions :-)


I think that you should still be able to select footprints even if the 
"front pads" is hidden from layers like the paste layer, *unless* you 
are in high contrast mode.


-Jon

On Fri, Mar 2, 2018 at 3:53 AM, Andrzej Wolski 
> wrote:


I've tried this patch, and there is a small issue: if you have
only eg front paste layer enabled and front pads are hidden,
footprint is still selectable.

Andrzej


W dniu 2018-02-27 o 04:11, Jon Evans pisze:

This patch changes the selection logic for footprints to fix a
reported issue[1] and to make the behavior more logical to me.

I know that correct selection behavior is something of a personal
preference, so I'm ready to be flamed :-)

The new behavior:

A footprint may be selected if:
1) The corresponding "Footprints" switch is on in the Items tab, AND
2) One or more of the layers that the footprint draws on is visible

This means that if all of the layers are turned off, footprints
are not selectable (fixes the bug), but it also means that now
footprints can be selected if any draw layers are visible (for
example, if you have only F.Mask enabled, you can select a
footprint that has solder mask and is on the front layer).

Before anyone complains, this is only if high-contrast mode is
turned OFF.  When it is on, you can still only select items that
*only* exist on that layer (to make moving silkscreen around
easier, for example)

Even though this adds some more for-loops to selection filtering,
I have not noticed any performance hits on some selection of
large boards that I tested.  More testing is welcome.

[1] https://bugs.launchpad.net/kicad/+bug/1751960


-Jon


___
Mailing list:https://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] Mac HighDPI performance

[Andy Peters]

> On Mar 1, 2018, at 8:53 PM, Seth Hillbrand  wrote:
> 
> Andrey-
> 
> I'm moving this to a new thread so that we don't conflate the OpenMP 
> discussion with this.
> 
> Can you test running Kicad with the "Open in Low Resolution" mode enabled?  
> You can activate this by choosing "Get Info" on the main KiCad application 
> and checking the option that says "Open in Low Resolution".  You may need to 
> do the same for the other applications (Eeschema, pcbnew, etc) as well.

testing on my 2017” touch-bar MBP … 

Good g-d, low-res mode looks fuzzy and weird!

I don’t notice any specific differences in EESchema performance. Maybe my 
schematic isn’t busy enough? I’m a fan of using more smaller sheets with less 
info on each than one big sheet with everything.

I know, anecdote is not evidence.

-a


> 
> -Seth
> 
> ​​2018-03-01 18:09 GMT-08:00 Andrey Kuznetsov :
> Hi,
> 
> So for now I've had a chance to test the motherboard project on my Retina 
> macbook display.
> eeschema: horrible zoom, feels like elastic band zoom and I have all scroll 
> wheel accelerations and similar disabled, zoom response is super laggy, 
> cannot work like this, will need to make schematics on windows.
> pcbnew by order of slowness:
> legacy - pretty slow, zoom lag is major, boo boo
> modern (fallback) - decent, but the lag can be felt, zoom lag is minor
> modern (accelerated) - almost cannot feel the lag, very nice, nice zoom 
> responsiveness
> 
> I'll report tomorrow on 5K LG display.
> ​


___
Mailing list: https://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] Mac HighDPI performance

[Jon Evans]

Hi Andrey,

I just tried some and I didn't see a large difference in zoom behavior
between eeschema and pcbnew.  They do use different zoom mechanisms when
you use Modern toolset in PcbNew, but the difference is minor.
Eeschema is not hardware-accelerated so I would expect that running it in
low resolution mode makes a much bigger difference than with PcbNew in
Modern toolset.

-Jon

On Fri, Mar 2, 2018 at 12:52 AM, Andrey Kuznetsov 
wrote:

> Thanks, I didn't know that, Open in Low Resolution definitely speeds up
> eeschema, I know kicad has this info on the website, however that fact that
> you have to go inside the package and set that to low res mode as far as I
> remember was not stated!
>
> The docs should be updated to properly show how to enable low res mode,
> step by step! Setting the main kicad.app to low res mode is not enough,
> eeschema.app inside kicad.app package needs to be set.
>
> It didn't feel like pcbnew got faster, I'll have to try on 5K monitor and
> I found some supersampling and anti-aliasing modes that I want to turn on
> to check.
>
> Thank you to someone on the dev team I guess for getting rid of the mouse
> warp events from right click, however the zoom mouse warp to the center of
> the screen is still a major WTF.
>
> Question: Is there something different in the way pcbnew does the zooming
> compared to eeschema? My mouse zooming feels weird in escheema, but not in
> pcbnew.
> I think pcbnew has a linear incremental step and the zooming is crisp,
> display changes per mouse wheel click, while eeschema what feels like
> rubber banding between wheel clicks, step sizes are not linear thus causing
> zooming ooogles. My mouse is a logitech mx master 2s using the ratchet
> mode. In pcbnew, the zoom happens every ratchet, while in eeschema the zoom
> can happen inbetween ratchets, like I just tilt the wheel and bring it back
> but the zoom changed in one direction only, ie I can zoom all the way in
> without ratcheting. In pcbnew you cannot do that, and it feels natural.
>
>
> Bug or not? When I open eeschema and pcbnew from KiCad app, eeschema opens
> as a standalone app and shows up in the dock on macOS while pcbnew opens as
> another window that's part of kicad app. This caused issues with my logitec
> options software for custom mouse button settings because I only programmed
> kicad, but not eeschema.
>
> On Thu, Mar 1, 2018 at 8:37 PM, Seth Hillbrand 
> wrote:
>
>> Usually, Eeschema, Pcbnew, etc are links into the KiCad package.  If you
>> right-click and go to "Show Original", you will get the actual
>> application.  Get Info there will allow you to select "Open in Low
>> Resolution" for that application.
>>
>> -S
>>
>> 2018-03-02 4:00 GMT+00:00 Andrey Kuznetsov :
>>
>>> Only KiCad app has Open in Low Resolution Mode, and I already had it
>>> enabled!
>>>
>>> On Thu, Mar 1, 2018 at 7:53 PM, Seth Hillbrand >> > wrote:
>>>
 Andrey-

 I'm moving this to a new thread so that we don't conflate the OpenMP
 discussion with this.

 Can you test running Kicad with the "Open in Low Resolution" mode
 enabled?  You can activate this by choosing "Get Info" on the main KiCad
 application and checking the option that says "Open in Low Resolution".
 You may need to do the same for the other applications (Eeschema, pcbnew,
 etc) as well.

 -Seth

 ​
 ​
 2018-03-01 18:09 GMT-08:00 Andrey Kuznetsov :

> Hi,
>
> So for now I've had a chance to test the motherboard project on my
> Retina macbook display.
> eeschema: horrible zoom, feels like elastic band zoom and I have all
> scroll wheel accelerations and similar disabled, zoom response is super
> laggy, cannot work like this, will need to make schematics on windows.
> pcbnew by order of slowness:
> legacy - pretty slow, zoom lag is major, boo boo
> modern (fallback) - decent, but the lag can be felt, zoom lag is minor
> modern (accelerated) - almost cannot feel the lag, very nice, nice
> zoom responsiveness
>
> I'll report tomorrow on 5K LG display.
>
 ​


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


>>>
>>>
>>> --
>>> Remember The Past, Live The Present, Change The Future
>>> Those who look only to the past or the present are certain to miss the
>>> future [JFK]
>>>
>>> kandre...@gmail.com
>>> Live Long and Prosper,
>>> Andrey
>>>
>>
>>
>
>
> --
> Remember The Past, Live The Present, Change The Future
> Those who look only to the past or the present are certain to miss the
> future [JFK]
>
> kandre...@gmail.com
> Live Long and Prosper,
> Andrey
>
> 

Re: [Kicad-developers] New lead developers

[Tomasz Wlostowski]

On 01/03/18 20:15, Wayne Stambaugh wrote:
> Please
> congratulate Jon Evans, Seth Hillbrand, and Jeff Young for their
> promotion to the lead developers team. 

Congratulations gentlemen! Let's make KiCad great together!

Tom

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

Re: [Kicad-developers] [PATCH] Rework footprint selection filtering to improve behavior

[Jon Evans]

Hi Andrzej,

This was my intention, which is why I said I was prepared for other people
to have other opinions :-)

I think that you should still be able to select footprints even if the
"front pads" is hidden from layers like the paste layer, *unless* you are
in high contrast mode.

-Jon

On Fri, Mar 2, 2018 at 3:53 AM, Andrzej Wolski 
wrote:

> I've tried this patch, and there is a small issue: if you have only eg
> front paste layer enabled and front pads are hidden, footprint is still
> selectable.
>
> Andrzej
>
>
> W dniu 2018-02-27 o 04:11, Jon Evans pisze:
>
> This patch changes the selection logic for footprints to fix a reported
> issue[1] and to make the behavior more logical to me.
>
> I know that correct selection behavior is something of a personal
> preference, so I'm ready to be flamed :-)
>
> The new behavior:
>
> A footprint may be selected if:
> 1) The corresponding "Footprints" switch is on in the Items tab, AND
> 2) One or more of the layers that the footprint draws on is visible
>
> This means that if all of the layers are turned off, footprints are not
> selectable (fixes the bug), but it also means that now footprints can be
> selected if any draw layers are visible (for example, if you have only
> F.Mask enabled, you can select a footprint that has solder mask and is on
> the front layer).
>
> Before anyone complains, this is only if high-contrast mode is turned
> OFF.  When it is on, you can still only select items that *only* exist on
> that layer (to make moving silkscreen around easier, for example)
>
> Even though this adds some more for-loops to selection filtering, I have
> not noticed any performance hits on some selection of large boards that I
> tested.  More testing is welcome.
>
> [1] https://bugs.launchpad.net/kicad/+bug/1751960
>
> -Jon
>
>
> ___
> Mailing list: https://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 lead developers

[Kristoffer Ödmark]

Congratulations! I am very glad to see this! I have been following the 
mailing list for a while now and seen the great contributions and ideas 
from you guys! Well deserved promotion!


 -Kristoffer

On 2018-03-02 15:05, David Novak wrote:

Great job guys! Thanks for your investment in the project.

David




On 3/2/2018 2:40 AM, Maciej Sumiński wrote:

Congratulations fellow developers! You have received well deserved
promotions, and I am glad to see your names in the
kicad-product-committers group. Keep on rocking!

Cheers,
Orson

On 03/01/2018 08:15 PM, Wayne Stambaugh wrote:

I am pleased to announce the promotion of three developers to the KiCad
lead development team.  Their efforts since joining the project have
really helped move KiCad forward.  They have shown excellent technical
skills and a willingness to cooperate with the development team.  Please
congratulate Jon Evans, Seth Hillbrand, and Jeff Young for their
promotion to the lead developers team.  Thank you gentlemen for all of
you hard work.

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



___
Mailing list: https://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 developers

[David Novak]

Great job guys! Thanks for your investment in the project.

David




On 3/2/2018 2:40 AM, Maciej Sumiński wrote:

Congratulations fellow developers! You have received well deserved
promotions, and I am glad to see your names in the
kicad-product-committers group. Keep on rocking!

Cheers,
Orson

On 03/01/2018 08:15 PM, Wayne Stambaugh wrote:

I am pleased to announce the promotion of three developers to the KiCad
lead development team.  Their efforts since joining the project have
really helped move KiCad forward.  They have shown excellent technical
skills and a willingness to cooperate with the development team.  Please
congratulate Jon Evans, Seth Hillbrand, and Jeff Young for their
promotion to the lead developers team.  Thank you gentlemen for all of
you hard work.

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

[Wayne Stambaugh]

LOL, I just replied to Miles.  Thanks Orson for helping out!

On 3/2/2018 8:36 AM, Maciej Sumiński wrote:
> Hi Miles,
> 
> I suppose the silence in the thread indicates there are not many
> developers knowing the Python scripting interface inside out. Since you
> are both studying the scripting interface and developing own scripts, it
> is quite possible you are the most competent person to give us an advice
> on how to proceed. See some comments below, but I am neither a Python
> script developer nor a scripting interface maintainer, so I might be
> lacking some basic knowledge here.
> 
> On 02/28/2018 05:12 PM, miles mccoo wrote:
>> So I'm plugin-ifying my python scripts (the mechanism is awesome). One of
>> the plugins deletes some stuff and that is causing trouble.
>>
>>
>>
>> I'm not sure how to fix the root cause. Hence this mail.
>>
>>
>>
>> The plugin just deletes Edge.Cuts[1]:
>> for d in board.GetDrawings():
>> if (d.GetLayerName() == 'Edge.Cuts'):
>> board.Remove(d)
>>
>>
>>
>> in board_item_container.i, I see this (with stuff deleted):
>> %rename(RemoveNative)BOARD_ITEM_CONTAINER::Remove;
>> def Remove(self,item):
>> self.RemoveNative(item)
>> item.thisown=1
>>
>>
>> Setting thisown tells, python "you own it". Delete it when you're done.
>> Which it does.
>>
>>
>> The problem this causes is that the plugin mechanism saves a list of all
>> objects before running the plugin and then checks if any of them has a null
>> list after (ie is it still in the design).
> 
> Is this mechanism implemented to handle memory leaks? If so, would not
> it be sufficient to stick to 'thisown' flag on Remove() calls or is
> there another way objects might be destroyed using Python scripts?
> 
>> Since the object has been deleted by python, the plugin stuff gets confused.
>>
>>
>> *So, the question is how to fix this?*
>>
>>
>> It appears that the plugin infrastructure will delete for you (that's what
>> I'm guessing), so the thisown setting shouldn't be done.
>>
>>
>> On the other hand, if running code from within a standalone script (ie from
>> regular python shell), now thisown'ing it would yield a memory leak.
>>
>>
>>
>> Perhaps the plugin stuff should have some sort of flag indicating "you're
>> in a plugin". Then the thisown setting could be conditional.
> 
> If the object listing mechanism is required for other reasons, then I
> suppose it is second best idea. Generally speaking, I would like to make
> the scripting interface convenient for the users, so they do not need to
> worry about whether their scripts are run standalone or as a plugin.
> Let's hide the dirty magic from them and make the coding process enjoyable.
> 
> Regards,
> Orson
> 
>> But I'm just a spectator. *I'm happy to put in the time to fix this but
>> need guidance on what approach to take.*
>>
>>
>> Miles
>>
>>
>>
>> [1] full plugin text
>> import pcbnew
>>
>> class RemoveBoundaryPlugin(pcbnew.ActionPlugin):
>> def defaults(self):
>> self.name = "Remove boundary"
>> self.category = "A descriptive category name"
>> self.description = "This plugin reads a dxf file and converts it to
>> a zone"
>>
>> def Run(self):
>> board = pcbnew.GetBoard()
>>
>> for d in board.GetDrawings():
>> print("{}".format(str(d)))
>> #print("on layer {} {} {}".format(d.GetLayerName(),
>> # str(d.GetStart()),
>> # str(d.GetEnd(
>> if (d.GetLayerName() == 'Edge.Cuts'):
>> board.Remove(d)
>>
>> RemoveBoundaryPlugin().register()
>>
>>
>>
>> ___
>> Mailing list: https://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] Deletion in plugins causing trouble

[Wayne Stambaugh]

Miles,

I wish I had a answer for your but you are probably on your own here
unless the developer who implemented this steps in and helps.  I don't
have the time to figure it out right now.  Maybe someone else can help
you or maybe you could become the resident python expert and maintain
this. ;)

Cheers,

Wayne

On 2/28/2018 11:12 AM, miles mccoo wrote:
> 
> 
> 
> So I'm plugin-ifying my python scripts (the mechanism is awesome). One
> of the plugins deletes some stuff and that is causing trouble.
> 
> 
> 
> I'm not sure how to fix the root cause. Hence this mail.
> 
> 
> 
> The plugin just deletes Edge.Cuts[1]:
> for d in board.GetDrawings():
>             if (d.GetLayerName() == 'Edge.Cuts'):
>                 board.Remove(d)
> 
> 
> 
> in board_item_container.i, I see this (with stuff deleted):
> %rename(RemoveNative)    BOARD_ITEM_CONTAINER::Remove;
>     def Remove(self,item):
>         self.RemoveNative(item)
>         item.thisown=1
> 
> 
> Setting thisown tells, python "you own it". Delete it when you're done.
> Which it does.
> 
> 
> The problem this causes is that the plugin mechanism saves a list of all
> objects before running the plugin and then checks if any of them has a
> null list after (ie is it still in the design).
> 
> Since the object has been deleted by python, the plugin stuff gets confused.
> 
> 
> *So, the question is how to fix this?*
> 
> 
> It appears that the plugin infrastructure will delete for you (that's
> what I'm guessing), so the thisown setting shouldn't be done.
> 
> 
> On the other hand, if running code from within a standalone script (ie
> from regular python shell), now thisown'ing it would yield a memory leak.
> 
> 
> 
> Perhaps the plugin stuff should have some sort of flag indicating
> "you're in a plugin". Then the thisown setting could be conditional.
> 
> 
> But I'm just a spectator. *I'm happy to put in the time to fix this but
> need guidance on what approach to take.*
> 
> 
> Miles
> 
> 
> 
> [1] full plugin text
> import pcbnew
> 
> class RemoveBoundaryPlugin(pcbnew.ActionPlugin):
>     def defaults(self):
>         self.name  = "Remove boundary"
>         self.category = "A descriptive category name"
>         self.description = "This plugin reads a dxf file and converts it
> to a zone"
> 
>     def Run(self):
>         board = pcbnew.GetBoard()
> 
>         for d in board.GetDrawings():
>             print("{}".format(str(d)))
>             #print("on layer {} {} {}".format(d.GetLayerName(),
>             #                                 str(d.GetStart()),
>             #                                 str(d.GetEnd(
>             if (d.GetLayerName() == 'Edge.Cuts'):
>                 board.Remove(d)
> 
> RemoveBoundaryPlugin().register()
> 
> 
> 
> ___
> Mailing list: https://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] Deletion in plugins causing trouble

[Maciej Sumiński]

Hi Miles,

I suppose the silence in the thread indicates there are not many
developers knowing the Python scripting interface inside out. Since you
are both studying the scripting interface and developing own scripts, it
is quite possible you are the most competent person to give us an advice
on how to proceed. See some comments below, but I am neither a Python
script developer nor a scripting interface maintainer, so I might be
lacking some basic knowledge here.

On 02/28/2018 05:12 PM, miles mccoo wrote:
> So I'm plugin-ifying my python scripts (the mechanism is awesome). One of
> the plugins deletes some stuff and that is causing trouble.
> 
> 
> 
> I'm not sure how to fix the root cause. Hence this mail.
> 
> 
> 
> The plugin just deletes Edge.Cuts[1]:
> for d in board.GetDrawings():
> if (d.GetLayerName() == 'Edge.Cuts'):
> board.Remove(d)
> 
> 
> 
> in board_item_container.i, I see this (with stuff deleted):
> %rename(RemoveNative)BOARD_ITEM_CONTAINER::Remove;
> def Remove(self,item):
> self.RemoveNative(item)
> item.thisown=1
> 
> 
> Setting thisown tells, python "you own it". Delete it when you're done.
> Which it does.
> 
> 
> The problem this causes is that the plugin mechanism saves a list of all
> objects before running the plugin and then checks if any of them has a null
> list after (ie is it still in the design).

Is this mechanism implemented to handle memory leaks? If so, would not
it be sufficient to stick to 'thisown' flag on Remove() calls or is
there another way objects might be destroyed using Python scripts?

> Since the object has been deleted by python, the plugin stuff gets confused.
> 
> 
> *So, the question is how to fix this?*
> 
> 
> It appears that the plugin infrastructure will delete for you (that's what
> I'm guessing), so the thisown setting shouldn't be done.
> 
> 
> On the other hand, if running code from within a standalone script (ie from
> regular python shell), now thisown'ing it would yield a memory leak.
> 
> 
> 
> Perhaps the plugin stuff should have some sort of flag indicating "you're
> in a plugin". Then the thisown setting could be conditional.

If the object listing mechanism is required for other reasons, then I
suppose it is second best idea. Generally speaking, I would like to make
the scripting interface convenient for the users, so they do not need to
worry about whether their scripts are run standalone or as a plugin.
Let's hide the dirty magic from them and make the coding process enjoyable.

Regards,
Orson

> But I'm just a spectator. *I'm happy to put in the time to fix this but
> need guidance on what approach to take.*
> 
> 
> Miles
> 
> 
> 
> [1] full plugin text
> import pcbnew
> 
> class RemoveBoundaryPlugin(pcbnew.ActionPlugin):
> def defaults(self):
> self.name = "Remove boundary"
> self.category = "A descriptive category name"
> self.description = "This plugin reads a dxf file and converts it to
> a zone"
> 
> def Run(self):
> board = pcbnew.GetBoard()
> 
> for d in board.GetDrawings():
> print("{}".format(str(d)))
> #print("on layer {} {} {}".format(d.GetLayerName(),
> # str(d.GetStart()),
> # str(d.GetEnd(
> if (d.GetLayerName() == 'Edge.Cuts'):
> board.Remove(d)
> 
> RemoveBoundaryPlugin().register()
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 




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

Re: [Kicad-developers] [PATCH] Restore some missing visibility items from board file

[Maciej Sumiński]

Thank you Andrzej, I have just merged your patch.

Cheers,
Orson

On 03/02/2018 01:52 AM, Andrzej Wolski wrote:
> I'm resending a patch from this thread:
> https://lists.launchpad.net/kicad-developers/msg34285.html
> 
> I believe it should go into rc2?
> 
> State of some recently added checkboxes to Render panel was not restored
> on file open. This patch fixes that.
> 
> Andrzej
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 




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

Re: [Kicad-developers] Mac HighDPI performance

[Kliment (Future Bits)]

On 02.03.2018 06:52, Andrey Kuznetsov wrote:

> Thank you to someone on the dev team I guess for getting rid of the mouse
> warp events from right click, however the zoom mouse warp to the center of
> the screen is still a major WTF.
That is an option in preferences -> general -> pan and zoom

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

Re: [Kicad-developers] [PATCH] Rework footprint selection filtering to improve behavior

[Andrzej Wolski]

I've tried this patch, and there is a small issue: if you have only eg 
front paste layer enabled and front pads are hidden, footprint is still 
selectable.


Andrzej


W dniu 2018-02-27 o 04:11, Jon Evans pisze:
This patch changes the selection logic for footprints to fix a 
reported issue[1] and to make the behavior more logical to me.


I know that correct selection behavior is something of a personal 
preference, so I'm ready to be flamed :-)


The new behavior:

A footprint may be selected if:
1) The corresponding "Footprints" switch is on in the Items tab, AND
2) One or more of the layers that the footprint draws on is visible

This means that if all of the layers are turned off, footprints are 
not selectable (fixes the bug), but it also means that now footprints 
can be selected if any draw layers are visible (for example, if you 
have only F.Mask enabled, you can select a footprint that has solder 
mask and is on the front layer).


Before anyone complains, this is only if high-contrast mode is turned 
OFF.  When it is on, you can still only select items that *only* exist 
on that layer (to make moving silkscreen around easier, for example)


Even though this adds some more for-loops to selection filtering, I 
have not noticed any performance hits on some selection of large 
boards that I tested.  More testing is welcome.


[1] https://bugs.launchpad.net/kicad/+bug/1751960

-Jon


___
Mailing list: https://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