[Kicad-developers] Patch set: Display Origin Transforms updates

[Reece R. Pollack]

I've attached a Zip file containing additional patches to be applied on 
top of the previous set.


The first three patch files address Wayne's code review comments. If 
anyone else had comments I didn't see them.


The fourth patch file provides support for Bezier control points. A big 
"thank you" goes to Seth Hillbrand for providing the example PCB file, 
which was very helpful.


The remaining two patch files provide support for the "Move Exactly", 
"Move Item", and "Create Array" dialogs which the first patch set didn't 
address.


I think this covers all of the places where Pcbnew displays coordinates 
and offsets to the user. If anyone sees something that is either not 
adjusted for the user-selected origin, or has the wrong sign, please let 
me know!


-Reece

<>
___
Mailing list: https://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] Atomic Libraries Proposal

[Seth Hillbrand]

Thanks Russ, that's helpful feedback.

Those actions are called out in the specification, so we should be able 
to work within the new format to allow the abilities regardless of the 
underlying file format.


The idea of footprint correctness is an interesting one.  That might fit 
nicely under a key/value pair.  If it is exported in the netlist to 
pcbnew, we can run that check as part of a dfm.


-Seth

Am 2019-05-23 20:04, schrieb Russell Oliver:

Maybe it can be implemented as not a new library format, but through
enhancements to the existing workflow and new symbol format.

If there was an ability to
a) filter symbols in eeschema that have a valid footprint that can be
found in the footprint library.
b) run a dfm check that flags symbols being used that aren't fully
defined.

Another idea i can think of is using hashes to link footprints and
symbols. Each symbol alias could have a linked footprint and a hash to
verify that the footprint is correct.

Cheers
Russ

On Fri, 24 May 2019, 9:29 am Seth Hillbrand, 
wrote:


Hi Rene-

That's a fair critique.  The main benefits are ones that could be
incorporated as separate tools (import/export, ability to switch
between
atomic and not, etc) once the new format is implemented.  In my use
case, it is useful to separate the definitions from the libraries
and
switch between atomic libraries, but that might not be sufficiently
common as to require an extra format.  Hence the request for
feedback on
the workflow.

-Seth

Am 2019-05-23 16:06, schrieb Rene Pöschl:

Hi Seth

What is the benefit compared to having lets say a more powerful
aliasing
system that allows bom specific things to be more easily included

in

the
kicad internal library without introducing something different?
(especially as i assume the new file format will provide a more
powerful
option in this regard anyways.)

On 23/05/19 21:41, Seth Hillbrand wrote:

Hi All-

After some discussion, we are trying to decide whether

implementing a

basic atomic library support would be useful during v6 or would

cause

more headache than worth while trying to work with the solution.

Background: "Atomic" libraries are ones that have unique names

for

symbol+footprint+properties combinations.  These are also

referred to

as
"Fully-specified" libraries or sometimes "house libraries".

The paradigm is outlined in a google document[1].  This is meant

to

provide an explicit option for users to create/utilize atomic

library

components without affecting the symbol or footprint formats.  It

is

also meant to be zero impact to the current, official KiCad

libraries.


The major limitations of the specification are:
- No editing of the atomic library file within KiCad
- The atomic library does not contain symbol or footprint data

Folks are welcomed to weigh in on whether this approach presents

a

viable work flow for them.  I'm happy to take suggestions on the
approach, I may ask you offline for some additional details of

how you

use KiCad and/or other tools with libraries at the moment.

Best-
Seth


[1]




https://docs.google.com/document/d/1FNPmUAkNVt7r9oz32OznDrqL8RHdGHpO-eiBVEzHCOs/edit?usp=sharing


___
Mailing list: https://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] Atomic Libraries Proposal

[Russell Oliver]

Maybe it can be implemented as not a new library format, but through
enhancements to the existing workflow and new symbol format.

If there was an ability to
a) filter symbols in eeschema that have a valid footprint that can be found
in the footprint library.
b) run a dfm check that flags symbols being used that aren't fully
defined.

Another idea i can think of is using hashes to link footprints and symbols.
Each symbol alias could have a linked footprint and a hash to verify that
the footprint is correct.

Cheers
Russ

On Fri, 24 May 2019, 9:29 am Seth Hillbrand,  wrote:

> Hi Rene-
>
> That's a fair critique.  The main benefits are ones that could be
> incorporated as separate tools (import/export, ability to switch between
> atomic and not, etc) once the new format is implemented.  In my use
> case, it is useful to separate the definitions from the libraries and
> switch between atomic libraries, but that might not be sufficiently
> common as to require an extra format.  Hence the request for feedback on
> the workflow.
>
> -Seth
>
> Am 2019-05-23 16:06, schrieb Rene Pöschl:
> > Hi Seth
> >
> > What is the benefit compared to having lets say a more powerful
> > aliasing
> > system that allows bom specific things to be more easily included in
> > the
> > kicad internal library without introducing something different?
> > (especially as i assume the new file format will provide a more
> > powerful
> > option in this regard anyways.)
> >
> > On 23/05/19 21:41, Seth Hillbrand wrote:
> >> Hi All-
> >>
> >> After some discussion, we are trying to decide whether implementing a
> >> basic atomic library support would be useful during v6 or would cause
> >> more headache than worth while trying to work with the solution.
> >>
> >> Background: "Atomic" libraries are ones that have unique names for
> >> symbol+footprint+properties combinations.  These are also referred to
> >> as
> >> "Fully-specified" libraries or sometimes "house libraries".
> >>
> >> The paradigm is outlined in a google document[1].  This is meant to
> >> provide an explicit option for users to create/utilize atomic library
> >> components without affecting the symbol or footprint formats.  It is
> >> also meant to be zero impact to the current, official KiCad libraries.
> >>
> >> The major limitations of the specification are:
> >> - No editing of the atomic library file within KiCad
> >> - The atomic library does not contain symbol or footprint data
> >>
> >> Folks are welcomed to weigh in on whether this approach presents a
> >> viable work flow for them.  I'm happy to take suggestions on the
> >> approach, I may ask you offline for some additional details of how you
> >> use KiCad and/or other tools with libraries at the moment.
> >>
> >> Best-
> >> Seth
> >>
> >>
> >> [1]
> >>
> https://docs.google.com/document/d/1FNPmUAkNVt7r9oz32OznDrqL8RHdGHpO-eiBVEzHCOs/edit?usp=sharing
> >>
> >> ___
> >> Mailing list: https://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] Atomic Libraries Proposal

[Rene Pöschl]

I still do not see that to be honest. Why would introducing a third 
element make anything saver? (Why would a verified triplet be superior 
to a verified fully specified symbol?)


Don't get me wrong the current (version 5) system has its weaknesses but 
i simply do not see how the proposed solution would be superior to what 
is already included in the new symbol file format (of version 6). Other 
than maybe making it more familiar to people coming from tools that went 
a similar way. But to users really care about the files or could this 
familiarity be better created with an improved GUI? I personally am kind 
of against doing something just because it is familiar. There should be 
a really good technical reason for it.


By the way i really do not understand why even the current v5 system 
would not allow for your use case. Make a library of fully specified and 
verified symbols. The only thing that i see it improving is that one can 
assign differing bom info or footprint connections to similar parts 
without duplicating symbols. But i kind of assumed the inheritance stuff 
of the new file format will do the same.


On 23/05/19 23:18, Drew Van Zandt wrote:
The benefit is that once you have verified a triplet works on a board, 
you can use it again without fear of error.  The current system is not 
ideal for re-use/production engineering.


On Thu, May 23, 2019, 4:06 PM Rene Pöschl > wrote:


Hi Seth

What is the benefit compared to having lets say a more powerful
aliasing
system that allows bom specific things to be more easily included
in the
kicad internal library without introducing something different?
(especially as i assume the new file format will provide a more
powerful
option in this regard anyways.)

On 23/05/19 21:41, Seth Hillbrand wrote:
> Hi All-
>
> After some discussion, we are trying to decide whether
implementing a
> basic atomic library support would be useful during v6 or would
cause
> more headache than worth while trying to work with the solution.
>
> Background: "Atomic" libraries are ones that have unique names for
> symbol+footprint+properties combinations.  These are also
referred to as
> "Fully-specified" libraries or sometimes "house libraries".
>
> The paradigm is outlined in a google document[1].  This is meant to
> provide an explicit option for users to create/utilize atomic
library
> components without affecting the symbol or footprint formats.  It is
> also meant to be zero impact to the current, official KiCad
libraries.
>
> The major limitations of the specification are:
> - No editing of the atomic library file within KiCad
> - The atomic library does not contain symbol or footprint data
>
> Folks are welcomed to weigh in on whether this approach presents a
> viable work flow for them.  I'm happy to take suggestions on the
> approach, I may ask you offline for some additional details of
how you
> use KiCad and/or other tools with libraries at the moment.
>
> Best-
> Seth
>
>
> [1]
>

https://docs.google.com/document/d/1FNPmUAkNVt7r9oz32OznDrqL8RHdGHpO-eiBVEzHCOs/edit?usp=sharing
>
> ___
> Mailing list: https://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] Atomic Libraries Proposal

[Drew Van Zandt]

The benefit is that once you have verified a triplet works on a board, you
can use it again without fear of error.  The current system is not ideal
for re-use/production engineering.

On Thu, May 23, 2019, 4:06 PM Rene Pöschl  wrote:

> Hi Seth
>
> What is the benefit compared to having lets say a more powerful aliasing
> system that allows bom specific things to be more easily included in the
> kicad internal library without introducing something different?
> (especially as i assume the new file format will provide a more powerful
> option in this regard anyways.)
>
> On 23/05/19 21:41, Seth Hillbrand wrote:
> > Hi All-
> >
> > After some discussion, we are trying to decide whether implementing a
> > basic atomic library support would be useful during v6 or would cause
> > more headache than worth while trying to work with the solution.
> >
> > Background: "Atomic" libraries are ones that have unique names for
> > symbol+footprint+properties combinations.  These are also referred to as
> > "Fully-specified" libraries or sometimes "house libraries".
> >
> > The paradigm is outlined in a google document[1].  This is meant to
> > provide an explicit option for users to create/utilize atomic library
> > components without affecting the symbol or footprint formats.  It is
> > also meant to be zero impact to the current, official KiCad libraries.
> >
> > The major limitations of the specification are:
> > - No editing of the atomic library file within KiCad
> > - The atomic library does not contain symbol or footprint data
> >
> > Folks are welcomed to weigh in on whether this approach presents a
> > viable work flow for them.  I'm happy to take suggestions on the
> > approach, I may ask you offline for some additional details of how you
> > use KiCad and/or other tools with libraries at the moment.
> >
> > Best-
> > Seth
> >
> >
> > [1]
> >
> https://docs.google.com/document/d/1FNPmUAkNVt7r9oz32OznDrqL8RHdGHpO-eiBVEzHCOs/edit?usp=sharing
> >
> > ___
> > Mailing list: https://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] Atomic Libraries Proposal

[Seth Hillbrand]

Hi Rene-

That's a fair critique.  The main benefits are ones that could be 
incorporated as separate tools (import/export, ability to switch between 
atomic and not, etc) once the new format is implemented.  In my use 
case, it is useful to separate the definitions from the libraries and 
switch between atomic libraries, but that might not be sufficiently 
common as to require an extra format.  Hence the request for feedback on 
the workflow.


-Seth

Am 2019-05-23 16:06, schrieb Rene Pöschl:

Hi Seth

What is the benefit compared to having lets say a more powerful 
aliasing
system that allows bom specific things to be more easily included in 
the

kicad internal library without introducing something different?
(especially as i assume the new file format will provide a more 
powerful

option in this regard anyways.)

On 23/05/19 21:41, Seth Hillbrand wrote:

Hi All-

After some discussion, we are trying to decide whether implementing a
basic atomic library support would be useful during v6 or would cause
more headache than worth while trying to work with the solution.

Background: "Atomic" libraries are ones that have unique names for
symbol+footprint+properties combinations.  These are also referred to 
as

"Fully-specified" libraries or sometimes "house libraries".

The paradigm is outlined in a google document[1].  This is meant to
provide an explicit option for users to create/utilize atomic library
components without affecting the symbol or footprint formats.  It is
also meant to be zero impact to the current, official KiCad libraries.

The major limitations of the specification are:
- No editing of the atomic library file within KiCad
- The atomic library does not contain symbol or footprint data

Folks are welcomed to weigh in on whether this approach presents a
viable work flow for them.  I'm happy to take suggestions on the
approach, I may ask you offline for some additional details of how you
use KiCad and/or other tools with libraries at the moment.

Best-
Seth


[1]
https://docs.google.com/document/d/1FNPmUAkNVt7r9oz32OznDrqL8RHdGHpO-eiBVEzHCOs/edit?usp=sharing

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

[Wayne Stambaugh]

John,

On 5/22/19 5:39 AM, John Beard wrote:
> On 20/05/2019 23:48, Frank Severinsen wrote:
> 
>> When using clang-format on the entire file, it more or less changed
>> every line in one way or another.
>> should this be committed as well or is git clutter worse than
>> codingstyle issues?
> 
> You should not commit unrelated formatting clutter in the same commit as
> actual code changes. Just format the changed bits. If that's too
> inconsistent, either reformat as a separate commit, or match the
> existing style in the area, even if it's "wrong".
> 
> The trick here is to use git-clang-format. This will only format the
> lines you have changed. There are instructions in the developer
> documentation[1], a git-hook to report errors when you commit, and a
> script to help you fix it.
> 
> @Wayne: I have a patch here for the formatting document to add some
> aliases to make it easier. It finally dawned on me that we already
> distribute aliases for the 'fixes' alias, so let's do it for the
> formatting too!

Looks good to me.

Wayne

> 
> [1]:
> http://docs.kicad-pcb.org/doxygen/md_Documentation_development_coding-style-policy.html
> 
> 
> ___
> Mailing list: https://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: exact match of component with sub-units in schematic did not show

[Wayne Stambaugh]

On 5/22/19 4:38 AM, John Beard wrote:
> Hi Wayne,
> 
> On 21/05/2019 18:26, Wayne Stambaugh wrote:
>> John,
>>
>> If this is not acceptable, would an option that allows the user to turn
>> this feature on or off be an acceptable solution.  In some use cases, I
>> can see the value of the this patch.
> 
> I'm not saying it's unacceptable, I'm just not sure the attached
> "expanded" behaviour is what you want to see (by default), because you
> get so few results on a page (if the symbols in the results have many
> subunits, it could be only one). It's certainly a judgment call. What
> would you like to see here?

I'm fine with the current behavior but some users may prefer the
expanded subunit behavior.  I just don't want the expanded subunit
behavior to be the only one.  An option would handle this nicely.

> 
>> If John, is OK with a user option, would you be OK with making this
>> behavior user configurable?
> 
> If configuration *is* wanted, something like a checkbox somewhere in
> that dialog for "expand subunits" would probably be a good place, so it
> can be changed quickly as needed. But if it's a checkbox "in the clear"
> in the dialog (as opposed to in a context menu or otherwise hidden),
> it's a space-function trade-off.

Putting the option in the file chooser is probably less than ideal.
This dialog is already pretty crowded.  It seems like the best place for
this option would be in the Eeschema preferences dialog but I'm open to
suggestion on this.

> 
> Cheers,
> 
> John

___
Mailing list: https://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] Atomic Libraries Proposal

[Rene Pöschl]

Hi Seth

What is the benefit compared to having lets say a more powerful aliasing
system that allows bom specific things to be more easily included in the
kicad internal library without introducing something different?
(especially as i assume the new file format will provide a more powerful
option in this regard anyways.)

On 23/05/19 21:41, Seth Hillbrand wrote:

Hi All-

After some discussion, we are trying to decide whether implementing a
basic atomic library support would be useful during v6 or would cause
more headache than worth while trying to work with the solution.

Background: "Atomic" libraries are ones that have unique names for
symbol+footprint+properties combinations.  These are also referred to as
"Fully-specified" libraries or sometimes "house libraries".

The paradigm is outlined in a google document[1].  This is meant to
provide an explicit option for users to create/utilize atomic library
components without affecting the symbol or footprint formats.  It is
also meant to be zero impact to the current, official KiCad libraries.

The major limitations of the specification are:
- No editing of the atomic library file within KiCad
- The atomic library does not contain symbol or footprint data

Folks are welcomed to weigh in on whether this approach presents a
viable work flow for them.  I'm happy to take suggestions on the
approach, I may ask you offline for some additional details of how you
use KiCad and/or other tools with libraries at the moment.

Best-
Seth


[1]
https://docs.google.com/document/d/1FNPmUAkNVt7r9oz32OznDrqL8RHdGHpO-eiBVEzHCOs/edit?usp=sharing

___
Mailing list: https://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] Atomic Libraries Proposal

[Seth Hillbrand]

Hi All-

After some discussion, we are trying to decide whether implementing a 
basic atomic library support would be useful during v6 or would cause 
more headache than worth while trying to work with the solution.


Background: "Atomic" libraries are ones that have unique names for 
symbol+footprint+properties combinations.  These are also referred to as 
"Fully-specified" libraries or sometimes "house libraries".


The paradigm is outlined in a google document[1].  This is meant to 
provide an explicit option for users to create/utilize atomic library 
components without affecting the symbol or footprint formats.  It is 
also meant to be zero impact to the current, official KiCad libraries.


The major limitations of the specification are:
- No editing of the atomic library file within KiCad
- The atomic library does not contain symbol or footprint data

Folks are welcomed to weigh in on whether this approach presents a 
viable work flow for them.  I'm happy to take suggestions on the 
approach, I may ask you offline for some additional details of how you 
use KiCad and/or other tools with libraries at the moment.


Best-
Seth


[1] 
https://docs.google.com/document/d/1FNPmUAkNVt7r9oz32OznDrqL8RHdGHpO-eiBVEzHCOs/edit?usp=sharing


___
Mailing list: https://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] Linux builds broken.

[Wayne Stambaugh]

John,

On 5/23/19 2:36 PM, John Beard wrote:
> On 23/05/2019 19:05, Wayne Stambaugh wrote:
> 
>> /home/wayne/src/kicad-trunk/include/bitmap_base.h:34:1: error:
>> declaration
>>    conflicts with target of using declaration already in scope
>> class COLOR4D;
> 
> Odd, I don't see this at all, even on Jenkins. Must be a compiler thing?
> 
> COLOR4D is actually in KIGFX, but it's a bit confused, as there are as
> few using directives in headers hoiking it out of its namespace.
> 
> I've pushed a fix that I think will fix it.

That fixed it.  Thanks.

Wayne

> 
> Cheers,
> 
> John
> 
> ___
> Mailing list: https://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] Linux builds broken.

[John Beard]

On 23/05/2019 19:05, Wayne Stambaugh wrote:


/home/wayne/src/kicad-trunk/include/bitmap_base.h:34:1: error: declaration
   conflicts with target of using declaration already in scope
class COLOR4D;


Odd, I don't see this at all, even on Jenkins. Must be a compiler thing?

COLOR4D is actually in KIGFX, but it's a bit confused, as there are as 
few using directives in headers hoiking it out of its namespace.


I've pushed a fix that I think will fix it.

Cheers,

John

___
Mailing list: https://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] Show grid in eeschema status line

[Steven A. Falco]

On 5/23/19 1:59 PM, Wayne Stambaugh wrote:
> Hey Steve,
> 
> Adding "grid" to the coordinates in the status bar is not correct.
> These are the cursor coordinates not the grid coordinates.  To add the
> current grid size to the status bar, you would need to add another pane
> to status bar and fetch the current grid setting from the current SCREEN
> object.

Thanks!  I'll play around with that.

Steve

> 
> Cheers,
> 
> Wayne
> 
> On 5/18/19 3:48 PM, Steven A. Falco wrote:
>> I decided to try adding the current grid size to the status line of eeschema 
>> and the symbol editor, so as to make the N/shift-N hotkeys easier to use.  
>> Below is what I came up with.
>>
>> Is this something that could be accepted?  I don't know if it fits with the 
>> style of the KiCad code - I have mostly written embedded C SW, not C++.
>>
>>  Steve
>>
>> --- eeschema/sch_base_frame.cpp  2019-05-18 15:17:14.692949429 -0400
>> +++ /home/sfalco/sch_base_frame.cpp  2019-05-18 15:36:11.266193897 -0400
>> @@ -257,17 +246,17 @@
>>  {
>>  case INCHES:
>>  absformatter = "X %.3f  Y %.3f";
>> -locformatter = "dx %.3f  dy %.3f  dist %.3f";
>> +locformatter = "grid %.3f  dx %.3f  dy %.3f  dist %.3f";
>>  break;
>>  
>>  case MILLIMETRES:
>>  absformatter = "X %.2f  Y %.2f";
>> -locformatter = "dx %.2f  dy %.2f  dist %.2f";
>> +locformatter = "grid %.4f  dx %.2f  dy %.2f  dist %.2f";
>>  break;
>>  
>>  case UNSCALED_UNITS:
>>  absformatter = "X %f  Y %f";
>> -locformatter = "dx %f  dy %f  dist %f";
>> +locformatter = "grid %f  dx %f  dy %f  dist %f";
>>  break;
>>  
>>  case DEGREES:
>> @@ -282,6 +271,9 @@
>>  double dx = (double)GetCrossHairPosition().x - 
>> (double)screen->m_O_Curseur.x;
>>  double dy = (double)GetCrossHairPosition().y - 
>> (double)screen->m_O_Curseur.y;
>>  
>> +wxRealPoint curr_grid_size = GetScreen()->GetGridSize();
>> +double grid = To_User_Unit( GetUserUnits(), curr_grid_size.x );
>> +
>>  dXpos = To_User_Unit( GetUserUnits(), dx );
>>  dYpos = To_User_Unit( GetUserUnits(), dy );
>>  
>> @@ -292,9 +284,10 @@
>>  }
>>  
>>  // We already decided the formatter above
>> -line.Printf( locformatter, dXpos, dYpos, hypot( dXpos, dYpos ) );
>> +line.Printf( locformatter, grid, dXpos, dYpos, hypot( dXpos, dYpos ) );
>>  SetStatusText( line, 3 );
>>  
>>  // refresh units display
>>  DisplayUnitsMsg();
>>  }
>>
>> ___
>> Mailing list: https://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] Linux builds broken.

[Wayne Stambaugh]

Fat fingered:

On 5/23/19 2:04 PM, Wayne Stambaugh wrote:
> I just got this:
> 

[ 27%] Building CXX object
common/CMakeFiles/legacy_wx.dir/legacy_wx/eda_draw_frame.cpp.o
In file included from
/home/wayne/src/kicad-trunk/common/legacy_wx/eda_draw_frame.cpp:70:
In file included from
/home/wayne/src/kicad-trunk/include/worksheet_shape_builder.h:37:
/home/wayne/src/kicad-trunk/include/bitmap_base.h:34:1: error: declaration
  conflicts with target of using declaration already in scope
class COLOR4D;
^
/home/wayne/src/kicad-trunk/include/gal/color4d.h:39:7: note: target of
using
  declaration
class COLOR4D
  ^
/home/wayne/src/kicad-trunk/include/config_params.h:40:14: note: using
  declaration
using KIGFX::COLOR4D;
 ^
In file included from
/home/wayne/src/kicad-trunk/common/legacy_wx/eda_draw_frame.cpp:70:
In file included from
/home/wayne/src/kicad-trunk/include/worksheet_shape_builder.h:37:
/home/wayne/src/kicad-trunk/include/bitmap_base.h:246:21: error:
reference to
  'COLOR4D' is ambiguous
COLOR4D aDefaultColor, int aDefaultPensize );
^
/home/wayne/src/kicad-trunk/include/bitmap_base.h:34:7: note: candidate
found by
  name lookup is 'COLOR4D'
class COLOR4D;
  ^
/home/wayne/src/kicad-trunk/include/config_params.h:40:14: note:
candidate found
  by name lookup is 'COLOR4D'
using KIGFX::COLOR4D;
 ^
In file included from
/home/wayne/src/kicad-trunk/common/legacy_wx/eda_draw_frame.cpp:70:
/home/wayne/src/kicad-trunk/include/worksheet_shape_builder.h:66:5: error:
  reference to 'COLOR4D' is ambiguous
COLOR4D m_color;
^
/home/wayne/src/kicad-trunk/include/bitmap_base.h:34:7: note: candidate
found by
  name lookup is 'COLOR4D'
class COLOR4D;
  ^
/home/wayne/src/kicad-trunk/include/config_params.h:40:14: note:
candidate found
  by name lookup is 'COLOR4D'
using KIGFX::COLOR4D;
 ^
There is a whole lot more after 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

[Kicad-developers] Linux builds broken.

[Wayne Stambaugh]

I just got 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] Show grid in eeschema status line

[Wayne Stambaugh]

Hey Steve,

Adding "grid" to the coordinates in the status bar is not correct.
These are the cursor coordinates not the grid coordinates.  To add the
current grid size to the status bar, you would need to add another pane
to status bar and fetch the current grid setting from the current SCREEN
object.

Cheers,

Wayne

On 5/18/19 3:48 PM, Steven A. Falco wrote:
> I decided to try adding the current grid size to the status line of eeschema 
> and the symbol editor, so as to make the N/shift-N hotkeys easier to use.  
> Below is what I came up with.
> 
> Is this something that could be accepted?  I don't know if it fits with the 
> style of the KiCad code - I have mostly written embedded C SW, not C++.
> 
>   Steve
> 
> --- eeschema/sch_base_frame.cpp   2019-05-18 15:17:14.692949429 -0400
> +++ /home/sfalco/sch_base_frame.cpp   2019-05-18 15:36:11.266193897 -0400
> @@ -257,17 +246,17 @@
>  {
>  case INCHES:
>  absformatter = "X %.3f  Y %.3f";
> -locformatter = "dx %.3f  dy %.3f  dist %.3f";
> +locformatter = "grid %.3f  dx %.3f  dy %.3f  dist %.3f";
>  break;
>  
>  case MILLIMETRES:
>  absformatter = "X %.2f  Y %.2f";
> -locformatter = "dx %.2f  dy %.2f  dist %.2f";
> +locformatter = "grid %.4f  dx %.2f  dy %.2f  dist %.2f";
>  break;
>  
>  case UNSCALED_UNITS:
>  absformatter = "X %f  Y %f";
> -locformatter = "dx %f  dy %f  dist %f";
> +locformatter = "grid %f  dx %f  dy %f  dist %f";
>  break;
>  
>  case DEGREES:
> @@ -282,6 +271,9 @@
>  double dx = (double)GetCrossHairPosition().x - 
> (double)screen->m_O_Curseur.x;
>  double dy = (double)GetCrossHairPosition().y - 
> (double)screen->m_O_Curseur.y;
>  
> +wxRealPoint curr_grid_size = GetScreen()->GetGridSize();
> +double grid = To_User_Unit( GetUserUnits(), curr_grid_size.x );
> +
>  dXpos = To_User_Unit( GetUserUnits(), dx );
>  dYpos = To_User_Unit( GetUserUnits(), dy );
>  
> @@ -292,9 +284,10 @@
>  }
>  
>  // We already decided the formatter above
> -line.Printf( locformatter, dXpos, dYpos, hypot( dXpos, dYpos ) );
> +line.Printf( locformatter, grid, dXpos, dYpos, hypot( dXpos, dYpos ) );
>  SetStatusText( line, 3 );
>  
>  // refresh units display
>  DisplayUnitsMsg();
>  }
> 
> ___
> Mailing list: https://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] Fixes for the github 3D library fetching dialog

[Wayne Stambaugh]

Thanks Seth!

On 5/23/19 1:08 PM, Seth Hillbrand wrote:
> It looks like this was the same one that went to the bug tracker.
> 
> I tested it and pushed earlier this morning.
> 
> -Seth
> 
> Am 2019-05-23 12:55, schrieb Wayne Stambaugh:
>> JP,
>>
>> This patch looks correct to me but this is your code so please take a
>> look at this to see if it makes sense to you when you get a chance.
>>
>> Thanks,
>>
>> Wayne
>>
>> On 5/3/19 8:05 PM, Ian McInerney wrote:
>>> The attached patch modifies the behavior of the wizard for fetching the
>>> 3d libraries from github to fetch the list of libraries if the URL is
>>> modified by the user (e.g. if they go to page 2, then back to page 1 and
>>> modify the URL it will now fetch the library list for the modified URL).
>>> It also fixes an issue where the library list was not populating when
>>> first visiting the second page (it would only populate if you tried
>>> searching or went back to page 1 and then page 2).
>>>
>>> -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] [Patch] Fixes for the github 3D library fetching dialog

[Ian McInerney]

Yes, this is the same one I put on the tracker this morning. I figured that
way it wouldn't get lost as easily.

-Ian

On Thu, 23 May 2019, 6:08 p.m. Seth Hillbrand,  wrote:

> It looks like this was the same one that went to the bug tracker.
>
> I tested it and pushed earlier this morning.
>
> -Seth
>
> Am 2019-05-23 12:55, schrieb Wayne Stambaugh:
> > JP,
> >
> > This patch looks correct to me but this is your code so please take a
> > look at this to see if it makes sense to you when you get a chance.
> >
> > Thanks,
> >
> > Wayne
> >
> > On 5/3/19 8:05 PM, Ian McInerney wrote:
> >> The attached patch modifies the behavior of the wizard for fetching
> >> the
> >> 3d libraries from github to fetch the list of libraries if the URL is
> >> modified by the user (e.g. if they go to page 2, then back to page 1
> >> and
> >> modify the URL it will now fetch the library list for the modified
> >> URL).
> >> It also fixes an issue where the library list was not populating when
> >> first visiting the second page (it would only populate if you tried
> >> searching or went back to page 1 and then page 2).
> >>
> >> -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
>
___
Mailing list: https://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] Fixes for the github 3D library fetching dialog

[Seth Hillbrand]

It looks like this was the same one that went to the bug tracker.

I tested it and pushed earlier this morning.

-Seth

Am 2019-05-23 12:55, schrieb Wayne Stambaugh:

JP,

This patch looks correct to me but this is your code so please take a
look at this to see if it makes sense to you when you get a chance.

Thanks,

Wayne

On 5/3/19 8:05 PM, Ian McInerney wrote:
The attached patch modifies the behavior of the wizard for fetching 
the

3d libraries from github to fetch the list of libraries if the URL is
modified by the user (e.g. if they go to page 2, then back to page 1 
and
modify the URL it will now fetch the library list for the modified 
URL).

It also fixes an issue where the library list was not populating when
first visiting the second page (it would only populate if you tried
searching or went back to page 1 and then page 2).

-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] Eeschema unit testing

[John Beard]

Hi Wayne,

On 16/05/2019 20:12, Wayne Stambaugh wrote:

I absolutely would like to see more Eeschema unit testing.  I'm going to
need it when I start on the new file format code.  Of course the usual
caveats like don't break anything apply.


I have pushed the first couple of commits for this. It seems to work:

* Arch (and the tests pass)
* Ubuntu 16.04 (and the tests pass)
* Jenkins Linux (and the tests pass)
* Jenkins Msys2
* Jenkins MSVC (and the tests pass)

There are a few fairly inoffensive things under test, as a demo, and 
also to underpin some changes I'd like to make in future.


I'd like to start to get the netlist code under test.

Cheers,

John



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