Re: [Kicad-developers] Stable release 4.0.7 status.

[Rene Pöschl]

On 16/08/17 01:35, Wayne Stambaugh wrote:

AFAIK we intend to use the 4.0.6 tag for libraries, docs, and i18n.  The
libraries in particular have changed significantly and I think it's a
bad idea to break users schematics on a point release.


Does the default setup of kicad use the github plugin to get up do date
footprints?
If so this will create inconsistencies within the lib. (If the symbol
and 3d model libs are not updated as well)

In particular there might be a problem if either a footprint has been
renamed.
(Footprint field or footprint filters of a symbol is now wrong.)

Or if the scaling, offset or rotation of 3d models changed within a
footprints 3d model settings.
(We got a lot of new correctly scaled models since the 4.0.6 release)

In my opinion it would be best if users can control when they receive
new libraries.
Each update should make sure that all 3 types of libraries are updated
at the same time. (to the same version)


About breaking users schematics:
I thought this should not happen as long as the user does not delete the
cache lib.
(The user should be prompted with the rescue symbols dialog next time
they open the schematic if any symbol has changed within the library.)


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

Re: [Kicad-developers] KiCad Libraries (again)

[Rene Pöschl]

On 19 Sep 2017 2:05 am, "José Ignacio"  wrote:

Probably, contributors would need to agree to be attributed as a group when
the work is embedded in a design (When the library is distributed in whole
or part they should get attributed individually as the GPL requires).
Ownership transfer shouldn't be necessary. a CLA is a good idea anyway to
ensure all contributions are licensed with all the terms you think they
are, and everyone is given proper attribution.


I think ownership transfer happens automatically when opening a pull
request. But having contributers sign an explicit agreement can't hurt.


IANAL but i think something that would make everyone happy is to have these
conditions apply:

1) When distributing the libraries in whole or in part the whole GPL
applies, with it's requirements on disclosure of source, copyleft, and
attribution.
2) In the special case of someone embedding the symbols in their design, a
simpler license would apply, where they can use a simplified attribution
requirement, people are forbidden from separating the symbols from the
design for their own use in other designs.


Did you read what we did for the 3d models repo? If I read your comment
correctly it means the same as we wrote there. If you think your suggestion
is not satisfied with this license could you give a specific list of
differences?

Here again the link to the 3d model licence page
https://github.com/KiCad/kicad-packages3D/wiki/Model-Licencing


The attribution requirement for case #2 ideally would be a simple "Using
symbols/footprints/models for the Kicad project's library, version X" plus
some permalink where the GPL versions of the libraries can be obtained,
together with the attribution information (embedded in the GIT history, or
preferably an AUTHORS file). If that's not agreeable, perhaps an AUTHORS
file that can be downloaded and bundled with a non-gpl design should comply
with the attribution requirement.


for #2 we used the font exception. We also have a credits file that has a
dual purpose of documenting where the models come from (script or mcad
software example freecad) and who made them. I don't think this would be
practical for other libs though. (it already creates merge conflicts in the
3d repo.)
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] KiCad Libraries (again)

[Rene Pöschl]

On 19/09/17 00:59, José Ignacio wrote:
The GPL with font exception is probably the better of the two, as it 
is the least restrictive one contributors seem to agree on



Well we use this already for the 3d model lib.
https://github.com/KiCad/kicad-packages3D/wiki/Model-Licencing

So it would actually suite us as well.

And back in 2015 Wayne also suggested the gEDA route in this message:
https://lists.launchpad.net/kicad-developers/msg21732.html 



This is the reason we went down that route for the 3d models.


On Mon, Sep 18, 2017 at 5:47 PM, Oliver Walters 
> wrote:


A further issue that has cropped up twice in the last hour:
Library licensing

https://github.com/KiCad/kicad-library/issues/1259#issuecomment-330374095



https://forum.kicad.info/t/default-libraries-gpl-licencing-vs-proprietary-designs/140/8




We have been discussing this for a while in this thread -
https://lists.launchpad.net/kicad-developers/msg28181.html


It initially looked like we had a consensus but then it quickly
devolved and never reached a conclusion.

*Without entering into the same back-and-forth again, *and with
the following stipulations:

a) All libraries will have the same license agreeement
b) A single LICENSE.md file will suffice

What license should we be using?

1. CC-BY-SA - This is what Wayne originally suggested IIRC
2. modified GPL similar to gEDA license?


I need a consensus on this so I can add the license files to the
repositories and add the information to the website.

Cheers,
Oliver




___
Mailing list: https://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] GitHub Plugin (my nemesis)

[Rene Pöschl]

On 02/10/17 11:37, Simon Küppers wrote:
I am no expert, but this question is out of the scope of this thread.. 
For downloading, gut applies compression anyway.


I respect the people having slow Internet lines.. However as shown a 
few posts backwards, the whole footprints and symbol library is like 
100 megabytes without the 3d models. If think the benefit of a single 
repo outways the ability to download only a selection of libraries... 
By a LOT.


I agree with you here. Lets ignore the 3d model stuff and get back 
talking about the footprint libs.

We are planning a massive library reorganization. (for the v5 release)
This will require a lot more footprint libs. If all these new libs are 
all in a separate repo then this can not be done!
In addition to the new repos the old once still need to exist (and have 
at least one footprint each) because otherwise the github plugin will 
stop working for everyone who has this old repo in their fp-lib-table.


**We library managers require whatever lib distribution is used to 
support one repo that holds all footprint libs.** (one repo that has the 
pretty folders as subdirectorys)
To be honest i do not care what will be used as long as this requirement 
is fulfilled.


We would really need a decision soon. Are you guys prepared to help us 
out here such that we can move on with the lib reorganization? (The 
details of how you do it can be discussed later.)


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

[Rene Pöschl]

On 12/10/17 15:12, Kristoffer Ödmark wrote:

Sorry for double messages but one solution could be to use the Library
stored documentation to autofill the FIELD variable IF it is empty. And
then base all the functionality on the field variable?

I could probably fix this if it seems an okay solution to everyone?
This would basically be making the field variable overriding the
properties information. But still not break anything from the libs.

Or should this just be left as is until the new symbool format is
implemented?

On 10/12/2017 03:00 PM, Kristoffer Ödmark wrote:

Hey!

I noticed today that there are two places to store the datasheet
information, one is in the Mandatory Field "Datasheet", and one is in
the porperty of the part in the lib. These have different functionality
in the schematic editor and in the library part editor.

I think these should somehow be merged or one of them removed. As it is
now, it is a bit confusing with the "Open Documentation" context menu,
and the "Show Datasheet" button in the properties editor.

For me, mergin every functionality into the field variable seems like
the most robust way, since most other tools are using these field
variables and that is the most accesible way, and since the Datasheet
field is mandatory anyway, but can still be empty.



The field variable is the same for all aliases.

That's why the kicad library convention does not allow it's use.

We only use the datasheet property that is stored in the dcm file. (This 
property can differ for every alias.)



___
Mailing list: https://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] GitHub Plugin (my nemesis)

[Rene Pöschl]

On 23/09/17 20:51, Thomas Kindler wrote:

The other suggestions were quite surprising to me -- Github API, downloading
individual subdirectories as .zip, abusing subversion (gasp), gitslave (last
updated 2012), etc. would be a big hurdle and WTF for new KiCAD users.

Sorry for the late response. (I have been quite busy the last few weeks.)
I think there is a misunderstanding here. Using the github api to 
download individual repos as zip is not what has been suggested. It is 
the way it is currently implemented and the reason for this whole thread 
is to find a better solution to this.




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

Re: [Kicad-developers] Stable release 4.0.7 status.

[Rene Pöschl]

On 24/08/17 21:03, Nick ^ wrote:
I have now added the Librarians team as write for those four repos. 
Please tag appropiately. I can tag them if HEAD is good enough.



Thanks. I pushed the tags.



___
Mailing list: https://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] Stable release 4.0.7 status.

[Rene Pöschl]

On 22/08/17 14:53, Wayne Stambaugh wrote:

Sorry about the delay but I was dealing with a family emergency all last
week.  Now that I'm getting caught up I really need to get stable
version 4.0.7 released.  Are there any outstanding issue remaining
before I make the release announcement?  I'm shooting for Friday or
Saturday.

On 8/17/2017 8:45 AM, Rene Pöschl wrote:

On 16/08/17 01:35, Wayne Stambaugh wrote:

AFAIK we intend to use the 4.0.6 tag for libraries, docs, and i18n.  The
libraries in particular have changed significantly and I think it's a
bad idea to break users schematics on a point release.

Does the default setup of kicad use the github plugin to get up do date
footprints?

Github.


If so this will create inconsistencies within the lib. (If the symbol
and 3d model libs are not updated as well)

I hadn't thought about that but you are correct.  Maybe it makes sense
to tag the library repo where it stands right now.  That being said, as
the footprints and library repo change, they may (will) eventually get
out of sync so this isn't an ideal solution.


I created the 4.0.7 tag on all our libs. (Well 4 footprint libs do not 
have tags yet because i do not have write access to these 4 libs. The 
good news is that these are very new libs with only a handful of 
footprints in them.)





In particular there might be a problem if either a footprint has been
renamed.
(Footprint field or footprint filters of a symbol is now wrong.)

Or if the scaling, offset or rotation of 3d models changed within a
footprints 3d model settings.
(We got a lot of new correctly scaled models since the 4.0.6 release)

In my opinion it would be best if users can control when they receive
new libraries.
Each update should make sure that all 3 types of libraries are updated
at the same time. (to the same version)

Unfortunately, we are not set up to handle this at the moment and I
would not ask our package devs to fix this for the 4.0.7 release.  It is
certainly something worth considering for the 5 stable release.
I am aware of the fact that over time the libs will again get out of 
sync. (I think everyone involved with the library is aware of this fact.)
The impact of our scaling changes will be reduced if users get an update 
of the 3d lib.




___
Mailing list: https://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] PCBNew / Footprint editor - "Special strings"

[Rene Pöschl]

On 18/10/17 12:50, Thomas Langås wrote:

On Wed, Oct 18, 2017 at 12:04 PM, Gaurav Juvekar
 wrote:

Summary:
- Does KiCad support having an F.Assembly and B.Assembly layer?
- Does KiCad support "special strings" like Altium's .Designator ?

I think F.Fab and B.Fab is what you want. Reference designator is supported using 
"REF**"

(I guess this mailinglist might be the wrong place for this discussion
now, but...)

So, I tried adding a text string to the component (in the footprint
editor) with REF** on the
F.Fab layer.  Afterwards I did change the footprints in the PCB
schematics, and now I
see REF** on the F.Fab layer, and not the actual reference designator.
I'm using a nightly build
that is 14 days old...


Odd Ref** should work.

But you can also try %R

You can take a look at the kicad library convention [1]. There we 
require the use of a second reference on the fab layer.


You can even look at a footprint of the standard lib that has this 
implemented. I could suggest the R_0805 [2] resistor from the 
Resistors_SMD lib.


[1]: https://github.com/KiCad/kicad-library/wiki/Kicad-Library-Convention

[2]: 
https://github.com/KiCad/Resistors_SMD.pretty/blob/master/R_0805.kicad_mod



___
Mailing list: https://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] Migrating old designs best practice

[Rene Pöschl]

On 24/11/17 04:47, hauptmech wrote:

I can confirm unconnected wires. It may be worth noting that I did not
preserve the -cache.lib file when I archived the design.

I also had an issue with an old asymmetric diode footprint having its
anode and cathode reversed when I used it in a new design. If pin
numbers in the library got swapped around, then now I know why.

For myself, I would much rather that the old library parts get loaded
with my old design instead of trying to convert old parts to new parts.
Is it unreasonable to do that? Load the design with the old parts and
then do the rescue/migration rename? That way the old parts go into the
-rescue.lib file unchanged except for a name modification. Including the
old parts lib (perhaps concatenated into one file) does not seem too
difficult.


If the symbols are still unchanged in the library then you would not 
need the cache lib. (The migration would simply point to the full name 
of the symbol including the library name. Unless i understand the 
process wrong.)


The cache lib is necessary if the symbol in the library does change or 
is deleted. If you also delete the cache lib, from where should KiCad 
get the information how your old symbol(s) looked like? (The symbol data 
is not stored inside the schematic files. It is only stored in the cache 
lib.)




___
Mailing list: https://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] Migrating old designs best practice

[Rene Pöschl]

On 24/11/17 12:38, hauptmech wrote:

On 24 Nov 2017 10:52 pm, "Rene Pöschl" <poesc...@gmail.com> wrote:

On 24/11/17 04:47, hauptmech wrote:


I can confirm unconnected wires. It may be worth noting that I did not
preserve the -cache.lib file when I archived the design.

I also had an issue with an old asymmetric diode footprint having its
anode and cathode reversed when I used it in a new design. If pin
numbers in the library got swapped around, then now I know why.

For myself, I would much rather that the old library parts get loaded
with my old design instead of trying to convert old parts to new parts.
Is it unreasonable to do that? Load the design with the old parts and
then do the rescue/migration rename? That way the old parts go into the
-rescue.lib file unchanged except for a name modification. Including the
old parts lib (perhaps concatenated into one file) does not seem too
difficult.


If the symbols are still unchanged in the library then you would not need
the cache lib. (The migration would simply point to the full name of the
symbol including the library name. Unless i understand the process wrong.)

The cache lib is necessary if the symbol in the library does change or is
deleted. If you also delete the cache lib, from where should KiCad get the
information how your old symbol(s) looked like? (The symbol data is not
stored inside the schematic files. It is only stored in the cache lib.)

These are not my symbols, they are kicad library symbols, for which i would
hope for either stability or a migration path.


So we can never ever change symbols?

It is not the responsibility of the library team to ensure that you 
archive your projects correctly.


(Also the lib is a git repo. So if you know when you made your project 
you can check out that old version of the lib.)



___
Mailing list: https://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] Is there a timeframe till the stable release will be announced

[Rene Pöschl]

We librarians would need to know how long we have until our library 
reorganization needs to be finished.


(The footprint lib reorganization is nearly done. Now we are working on 
the symbol libs.)



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

[Rene Pöschl]

I think Greg is referencing this forum conversation:
https://forum.kicad.info/t/pcbnew-sketch-mode-what-is-it/8429

There it was reported that the word sketch is used in the display 
options dialog for pcb_new.


On 19/11/17 00:30, Nick Østergaard wrote:

Where is the word "Sketch" used now?

2017-11-18 17:56 GMT+01:00 Greg Smith >:


If I developed a (very very small) patch for this change, would it
be potentially accepted?

There was a conversation on the forums about the wording: Use
"Outline" instead of "Sketch" to be consistent and clear.

Greg S.

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

[Rene Pöschl]

On 16/11/17 17:41, Kevin Cozens wrote:

On a side note, you might see a trailing / for the KISYS3DMOD environment
variable. That is there by default when you first run KiCad. I would remove
that extra character for consistency. So far I have not noticed any negative
effects when the path for KISYS3DMOD ends with a / character.


Did you use one of the newer footprints?
The new klc requires the 3dpath to include ${KISYS3DMOD}/ (Including the /)
So i guess this should be a problem if the / is included in KISYS3DMOD.



___
Mailing list: https://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] What are the smallest values for pad paste and mask clearances? Why can't polygon pads not use negative mask clearance?

[Rene Pöschl]

We (the librarians) discovered that our workflow (or is it a workaround 
for missing features) of defining special paste or mask areas does not 
work as intended.


We use paste or mask only pads (no copper, only past or mask selected, 
no pin number assigned) to specify mask/paste areas if we can not use 
the normal way of defining them. (example a large exposed pad needs 
split up paste areas.) These pads naturally have a clearance setting of 
0 which tells kicad that the project settings should be applied. (We did 
not think about that.)


To avoid this i assume we will need to set a small clearance in such 
pads as a workaround. What is the smallest value possible that can be used?



---


And a strange observation i made regarding polygon pads. One can not set 
a negative soldermask clearance on the pad level. (soldermask defined 
pad) But a negative clearance on the footprint level is possible. (and 
results in the expected mask area reduction.)



___
Mailing list: https://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] Fwd: Re: What are the smallest values for pad paste and mask clearances? Why can't polygon pads not use negative mask clearance?

[Rene Pöschl]

Forwarded as i accidentally pressed on "Answer" instead of "Answer 
mailing list":


How would you then design a footprint where you need the paste not to be
centered on the copper area (0201 resistors need this.)?
How would you design a footprint for a part including an exposed pad?
There the paste needs to be split up. (And yes we know our 65% paste
coverage rule will not be right for everyone but it should be ok for
most users.)

How would you design a footprint for a part with a large "exposed" pad
for thermal reasons that has a reduced are where the copper is actually
exposed. (such footprints typically require a different mask clearance
in x and y direction.)

How would you design a part where the copper pad should be a circle but
the paste pad a square? (It seems BGA footprints should be made that way
as it results in better paste stencil separation behavior)

How would you define mask defined pads for example for a BGA? (if 0 is
not a good idea for a clearance setting why should any other number be ok?)




On 27/04/18 21:36, Wayne Stambaugh wrote:

The smallest unit in board file geometry is 1nm.  However, all
tolerances are really determined by the capabilities of the board
manufacturer.  I think setting all the default pad and footprint
tolerances to zero and using the user's global settings is the proper
way to go.  The problem I see with setting the tolerance on these paste
and/or mask pads is the user may not notice that the tolerances are too
small for the board manufacturer.  The best case scenario is the boards
will be rejected by the manufacturer's DRC or in the worst case the
boards will not reflect what the user had intended and possibly fail.

On 04/27/2018 03:16 PM, Rene Pöschl wrote:

We (the librarians) discovered that our workflow (or is it a workaround
for missing features) of defining special paste or mask areas does not
work as intended.

We use paste or mask only pads (no copper, only past or mask selected,
no pin number assigned) to specify mask/paste areas if we can not use
the normal way of defining them. (example a large exposed pad needs
split up paste areas.) These pads naturally have a clearance setting of
0 which tells kicad that the project settings should be applied. (We did
not think about that.)

To avoid this i assume we will need to set a small clearance in such
pads as a workaround. What is the smallest value possible that can be used?


---


And a strange observation i made regarding polygon pads. One can not set
a negative soldermask clearance on the pad level. (soldermask defined
pad) But a negative clearance on the footprint level is possible. (and
results in the expected mask area reduction.)


___
Mailing list: https://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] Fwd: Re: What are the smallest values for pad paste and mask clearances? Why can't polygon pads not use negative mask clearance?

[Rene Pöschl]

Maybe a bit of further clarification will help.
We are talking about at least two different things here.

First issue is what i guess most of you have in mind. The thing about 
mask clearance. Here the normal way is of course to enter the 
restrictions of your board house globally into kicad.
But some very small and specialized components need extremely tight 
requirements. If you select such a component you already know that your 
manufacturer can produce with such tight requirements.


In most cases you don't want to have these tight requirements for all 
components on the board as it will increase the price. So you create a 
specialized footprint for this one component and don't want the global 
settings to interfere with your design. All other components on the 
board will use the global settings which allow for larger tolerances. 
(will increase yield)


And then there is the second topic of the paste stencil.
The global settings here are less for ensuring correct alignment and 
more for a global paste reduction. In most cases the manufacturer will 
take care of this. (This is why the default in kicad is 0)
But if you have a component with a large "exposed pad" in the middle you 
need to reduce paste on it in a controlled manner. Typically you aim for 
about 65% paste coverage and hope for 50% coverage after soldering.
This paste also needs to be split up. One reason for this is to allow 
gases to escape (better solder result). Another reason is such that the 
squeegee dose not bend too much. (would result in uneven paste application)


If the pad also includes vias for thermal conductivity you might choose 
to avoid the area around these vias with paste to reduce loss of paste. 
(Otherwise you might need to tend or even better fill the vias. -> more 
expensive)


In short: There are legitimate reasons why you might need tight control 
over the paste and mask layer. Most users who use reflow soldering will 
encounter some instance where they need to take control over the paste 
layer. People who work with very small components might also need to 
take control over the mask layer.


On 28/04/18 13:37, Strontium wrote:

On 28/04/18 18:51, jp charras wrote:

Le 28/04/2018 à 10:08, Eeli Kaikkonen a écrit :

It still looks to me that the original problem wasn't understood, and I wasn't 
able to make it
clear. A Solder Mask Defined footprint means that the solder mask opening is 
smaller than the
underlying copper area. It may also be differently shaped than the underlying 
copper pad. Also the
paste area may be differently shaped than the copper or solder mask. In these 
cases it should be
possible to define the mask and paste areas exactly, without adding or removing 
anything. The
logical way of doing it, if KiCad had took it into consideration, would be to 
draw the pad shape and
set the clearances to 0, and the pad would always keep the exact dimensions. 
But now, because 0 is a
special case and means "add here some other value" the pad dimensions - we are 
talking about
non-copper pads - will change unpredictably. This works for normal Non Solder 
Mask Defined pads with
copper, but not for pads which are mask only or paste only.

The only possible solution ATM is to give very small clearance values so that 
the original size of a
mask-only pad is for example 0.3x0.45mm and the efficient value will be 
0.31x0.450001mm. If the
clearances are left to 0 they can be anything, depending on the project's 
values, and the footprint
doesn't work anymore. Remember that modern Solder Mask Defined footprints are 
mostly very small and
tolerances are small. You can't add or remove 0.05mm without it going wrong.

I perfectly understood what you are saying.
But I do not agree with you.

but if "You can't add or remove 0.05mm without it going wrong" it means the 
final board can be wrong.
Just because the solder mask opening areas can be not at the place you are 
expecting, due to
registration issues.
I am thinking you are not taking in account this problem.
If you are thinking this problem does not exist, just set the solder mask 
margin to 0

JP, I agree with you about solder mask registration issues in the normal
course, however there are components with specified footprints (like the
one Eeli linked to) that have very tight tolerances.  Now, the fact that
those specifications exist means that it is possible (although it may be
expensive and not a normal process) to get registration of the solder
mask to meet or exceed the tolerances required of these footprints,
otherwise the footprint would not be defined this way.

Eeli is really talking about "features" of the footprint, and these
special "features" are modelled as a kind of pad, but are not really
pads.  In this situation I can see that a way to "disable" the global
clearances from having any effect for a particular "feature" pad would
be desirable.  Might be a useful thing for V6?

Steven


See for example http://www.ti.com/lit/ug/slra003d/slra003d.pdf

Re: [Kicad-developers] Fwd: Re: What are the smallest values for pad paste and mask clearances? Why can't polygon pads not use negative mask clearance?

[Rene Pöschl]

On 28/04/18 14:26, jp charras wrote:

you also must set the solder paste ratio clearance clearance to a very small 
value (for instance
0.1 %)


really? so if i set only the solderpaste clearance the global 
solderpaste ratio still overwrites my settings? That would be really 
strange behavior in my mind.


So what is the minimum for that then? This will affect far more parts 
then what the previos problem did because there are quite a few 
components that have copper pads with paste margin set but no paste ratio.



___
Mailing list: https://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] Was there a change in how the footprint name is stored inside the footprint files?

[Rene Pöschl]

It seems the footprint editor now includes the library name in the 
footprint name (first line of the footprint file)


Has this changed on purpose or is this a bug?


___
Mailing list: https://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] 5.0 RC2 / release status

[Rene Pöschl]

Hi all,

as promised in my last response the library repos are now tagged with 
5.0.0-rc2
If there is another major delay we might need to introduce a rc2.1 tag 
or something (or accept that at that time the libs are a bit older)


On 18/05/18 23:45, Wayne Stambaugh wrote:

Hi Rene,

On 05/18/2018 11:53 AM, Rene Pöschl wrote:

On 18/05/18 16:44, Wayne Stambaugh wrote:

If any of our doc and library devs are on this mailing list, please
forward this information so we aren't making major changes to the docs
and libraries at the last minute.


We have one important pull request open that i will fix up my self
tomorrow if the contributor does not fix the remaining issues him self.
(Removing duplicate power pins from symbols as this can be quite
dangerous if the user connects them multiple times.)

After this is merged i will tag the library with "5.0.0-rc2" (Tomorrow
evening)

After this tag is set we will no longer allow renaming of libs until v6
development. (Adding new libs will still be allowed.)

I'm OK with this.


I will also create a kicad 4 compatibility backport for this lib. (The
intention is to allow users to use the new library structure for new
projects even if they can not update to a nightly build. This should
reduce their work when they then switch over to kicad 5)

This backport will contain a reduced number of footprints as footprints
with custom or roundrect pads are not supported by kicad 4. I will also
backport the symbol libs. The 3d lib does not need any work in this
regard but i will still ad a separate release tag to make it easier for
users. Not sure if i will make a backport of the templates.
Creating this backport will take some time but i hope to have it done
one week after the rc2 tag is set.

Awesome!  I'm sure our v4 users will appreciate this.



Regarding the issue about footprint connection you reported in [1]:
All symbols that have a valid symbol in the footprint lib are now
correctly connected. Sadly a lot of symbols still need footprints to be
generated. (Symbols where in the lib that never had a valid footprint)
Some of this will be fixed after the rc2 release. This will not impact
the library structure so i assume we can include these changes in the
final v5 release. (It will simply add more footprints.)

That fine by me.  If we are going add new symbol libraries during v5, I
don't see any reason not to add new footprints and footprint libraries.
We should try to avoid wholesale renaming and/or moving of libraries and
their contents to avoid headaches for users.  If we have any major
library reorganizations, we can always create a v5 branch as we do for
the KiCad source.

Thank you for all of your hard work on the libraries.  They really have
come a long way since v4 was released.

Cheers,

Wayne


[1]: https://github.com/KiCad/kicad-symbols/issues/520

___
Mailing list: https://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] 5.0 RC2 / release status

[Rene Pöschl]

On 18/05/18 16:44, Wayne Stambaugh wrote:

If any of our doc and library devs are on this mailing list, please
forward this information so we aren't making major changes to the docs
and libraries at the last minute.



We have one important pull request open that i will fix up my self 
tomorrow if the contributor does not fix the remaining issues him self. 
(Removing duplicate power pins from symbols as this can be quite 
dangerous if the user connects them multiple times.)


After this is merged i will tag the library with "5.0.0-rc2" (Tomorrow 
evening)


After this tag is set we will no longer allow renaming of libs until v6 
development. (Adding new libs will still be allowed.)


I will also create a kicad 4 compatibility backport for this lib. (The 
intention is to allow users to use the new library structure for new 
projects even if they can not update to a nightly build. This should 
reduce their work when they then switch over to kicad 5)


This backport will contain a reduced number of footprints as footprints 
with custom or roundrect pads are not supported by kicad 4. I will also 
backport the symbol libs. The 3d lib does not need any work in this 
regard but i will still ad a separate release tag to make it easier for 
users. Not sure if i will make a backport of the templates.
Creating this backport will take some time but i hope to have it done 
one week after the rc2 tag is set.



Regarding the issue about footprint connection you reported in [1]:
All symbols that have a valid symbol in the footprint lib are now 
correctly connected. Sadly a lot of symbols still need footprints to be 
generated. (Symbols where in the lib that never had a valid footprint)
Some of this will be fixed after the rc2 release. This will not impact 
the library structure so i assume we can include these changes in the 
final v5 release. (It will simply add more footprints.)


[1]: https://github.com/KiCad/kicad-symbols/issues/520

___
Mailing list: https://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] As promised a version 4 backport of the version 5.0.0-rc2 libraries has been created

[Rene Pöschl]

Hi all,


We (the librarians) created a kicad 4.0.x backport of the version 5 
libraries.


This backport contains a reduced set of footprints that are compatible 
with kicad 4.


We also backported the symbol libs (without loss as the current libs do 
not use any v5 features)


Only limitation of the symbol libs is that some footprint filters do not 
work. (They include library names) This means the effected symbols are 
not as useful as they will be in kicad version 5.



The intention behind this is to make the transition period as painless 
as we can make it.



___
Mailing list: https://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] Upgrading from V4 to V5 resources?

[Rene Pöschl]

Another pitfall seems to be that users do not expect that they need to 
update their fp-lib-table after installing kicad 5.


Either they need to update the fp-lib-table to get the footprint library 
to the state of v5 or they would need to manually install the version 4 
symbol and 3d model libs to stay at the version 4 library.



On 17/06/18 19:05, Wayne Stambaugh wrote:

Adam,

AFAIK, there is not an upgrading reference but we should probably create
one.  Since the biggest change that has the potential to confuse users
is the symbol remapping, I will write a short document and add it to the
end of the KiCad users manual.

Cheers,

Wayne


On 06/17/2018 12:03 PM, Adam Wolf wrote:

Hi folks!

Do we have a good reference for users upgrading from V4 to V5, telling
them any important precautions they'll need to take, and maybe even
what they can expect to be different?  I would love to help to write
this for V6 but for V5 I am too swamped with macOS (but still
optimistic we can hit Wayne's current schedule).

If so, I would like to refer to this in the macOS README.

Adam

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


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




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

[Rene Pöschl]

What a coincidence. I will also be out of town for the next one and a 
half weeks.
As i can not guarantee that i will have internet access during this time 
it might be necessary that somebody else tags the final kicad 5 library 
release.

(I should be back at June the 10th late at night CET.)

So i would suggest you make an issue one or two days before the intended 
release date to notify the library team. (I already made one to warn 
them about this fact. See: 
https://github.com/KiCad/kicad-symbols/issues/712)


On 30/06/18 01:59, Wayne Stambaugh wrote:

I think we are good to go with rc3.  I'm going to tag it tomorrow unless
something comes up between now and then.  Once rc3 is tagged, I would
like to hold off on any commits that are not critical bug fixes.  Since
I will be out of the country all next week for vacation, this will give
users time to test rc3 builds.  If no critical issues arise during this
week, I will tag 5.0.0 when I get back.  If this is an issue for our
doc, library, or translation devs, please let me know.  Once our 5.0.0
builds are ready to go, I will make the stable release announcement and
proceed directly to the pub to celebrate.  We are getting close.  Thanks
again for all of your 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

Re: [Kicad-developers] rc3

[Rene Pöschl]

I just added the rc3 tag to the library. (A bit later than promised. 
Hope this is still ok.)


On 24/06/18 03:12, Rene Pöschl wrote:

I can add the rc3 tag to the library repos sometime Sunday afternoon.
(central European time)
A few minor corrections would still be nice to get into v5 but we do not
have any deal-breaker that would merit postponing v5 from our side.

On 23/06/18 17:15, Wayne Stambaugh wrote:

Let's try to get rc3 by tomorrow.  That will give us almost a week of
testing before the 30th.  If no major issues arise between now and then,
I will tag 5.0.0 on the 30th.  I will be traveling for vacation the
following week so this will give everyone time to get everything ready
for the stable 5 release.  I will make the release announcement after I
get back from vacation once everything is ready to go.  Thank you
everyone for your continued efforts and support of the KiCad project.

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

Re: [Kicad-developers] rc3

[Rene Pöschl]

I can add the rc3 tag to the library repos sometime Sunday afternoon. 
(central European time)
A few minor corrections would still be nice to get into v5 but we do not 
have any deal-breaker that would merit postponing v5 from our side.


On 23/06/18 17:15, Wayne Stambaugh wrote:

Let's try to get rc3 by tomorrow.  That will give us almost a week of
testing before the 30th.  If no major issues arise between now and then,
I will tag 5.0.0 on the 30th.  I will be traveling for vacation the
following week so this will give everyone time to get everything ready
for the stable 5 release.  I will make the release announcement after I
get back from vacation once everything is ready to go.  Thank you
everyone for your continued efforts and support of the KiCad project.

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

[Kicad-developers] How to help users handle updating from version 4 to version 5 with regards to fp-lib-table handling?

[Rene Pöschl]

Hello,


I know we are in feature freeze. It seems a lot of people struggle with 
the transition from kicad 4 to kicad 5. One of the things that could 
help a lot would be some way of forcing a reset of the user config 
directory contents to the default. (cold also help later on if for some 
reason the config directory got compromised.)


Especially for the fp-lib-table. It is really not obvious to a lot of 
people using the official library that this one would need to be reset 
after updating from kicad 4 to kicad 5. (The files for the official 
symbol and 3d libraries are updated. The sym-lib-table is "updated" as 
it never existed before. Meaning without user intervention the footprint 
library will be out of sync with all other types of libraries.)


I think a message in the installer should be the least that should be 
done. (But that one will only work where kicad has a specific 
installation tool.)


A message on first run of kicad 5 might be even better (maybe the 
message stating that the default sym-lib-table has been introduced could 
hint at the fact that the fp-lib-table might need resetting as well. Or 
a message with a tick-mark "do not show again".)



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

[Rene Pöschl]

template repo is now tagged (sorry forgot about that one)

On 30/06/18 23:56, Steven A. Falco wrote:

Thank you!

There are three repos not yet tagged with rc3 on github - two are probably 
awaiting translation work: kicad-doc and kicad-i18n.  Also not tagged: 
kicad-templates.  Once everything catches up to rc3, I will push them to Fedora 
Rawhide.

Steve

On 06/30/2018 08:50 AM, Wayne Stambaugh wrote:

I will do this when I tag rc3.  I think I have done it for every release tag.

On 06/30/2018 08:28 AM, Steven A. Falco wrote:

If possible, it would also be great if a tar file for -rc3 could be uploaded to 
launchpad, analogous to what was done for -rc2.

We do have an -rc2 build in the official Fedora Rawhide now, and I'm ready to 
step that up to -rc3 once available.

 Thanks,
 Steve

On 06/29/2018 10:15 PM, Adam Wolf wrote:

Folks, enjoy your vacations.  We've all earned them! :)

Wayne, if you could please announce on the list when you tag rc3, that
would be awesome.

Thanks!

Adam
On Fri, Jun 29, 2018 at 7:27 PM Rene Pöschl  wrote:

What a coincidence. I will also be out of town for the next one and a
half weeks.
As i can not guarantee that i will have internet access during this time
it might be necessary that somebody else tags the final kicad 5 library
release.
(I should be back at June the 10th late at night CET.)

So i would suggest you make an issue one or two days before the intended
release date to notify the library team. (I already made one to warn
them about this fact. See:
https://github.com/KiCad/kicad-symbols/issues/712)

On 30/06/18 01:59, Wayne Stambaugh wrote:

I think we are good to go with rc3.  I'm going to tag it tomorrow unless
something comes up between now and then.  Once rc3 is tagged, I would
like to hold off on any commits that are not critical bug fixes.  Since
I will be out of the country all next week for vacation, this will give
users time to test rc3 builds.  If no critical issues arise during this
week, I will tag 5.0.0 when I get back.  If this is an issue for our
doc, library, or translation devs, please let me know.  Once our 5.0.0
builds are ready to go, I will make the stable release announcement and
proceed directly to the pub to celebrate.  We are getting close.  Thanks
again for all of your 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


___
Mailing list: https://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] A reminder on Git commit comments

[Rene Pöschl]

Thanks for the reminder,
we will try to better our ways.

See: https://github.com/KiCad/kicad-symbols/issues/569

On 02/05/18 00:03, Reece R. Pollack wrote:
I'd like to make an observation on some of the Git commit comments I'm 
reading. Some of these commit log entries are really unhelpful.


When I was at University many, many years ago, students were taught to 
place comments in their code. Many misunderstood the purpose of 
comments, though, and would write code like this:


x = x + 1;   /* Add 1 to x */


While the comment is totally correct, it's also totally useless. I can 
/see/ that this line adds 1 to /x/; I don't need a comment to tell me 
that. As a programmer coming along later, what I need to know is /why/ 
1 is being added to /x/.


I'm seeing commit comments of the form "add one to x" in the KiCad 
repos. These comments are useless. For an example, look at this commit 
in the kicad-symbols repo:


commit 4ada78e26774c841ce8ec33e8b221d04fed1f4c7
    Author: Rene Pöschl <r.poes...@student.tugraz.at>
Date:   Fri Apr 20 11:14:47 2018 +0200

    Remove Connector_Specialized files.

Great. I can /see/ that these files are being removed. That's obvious 
from looking at the content of the commit. But there is no explanation 
of why these files were deleted. Don't tell me that there was 
discussion about this in email; even if that happened it's irrelevant. 
No one should have to go chasing through an email archive hoping to 
understand why a change was made. That's what the commit log entry is for.


I went back further in the Git logs for commits touching these files 
hoping to find a more illuminating commit comment, but found nothing 
helpful. In fact, I came across an earlier series of commits that are 
even /less/ helpful:


commit 467170586b106d00c4df185dc1683046e259b74c
Author: evanshultz <evanshu...@users.noreply.github.com>
Date:   Thu Apr 19 09:42:52 2018 -0700

    Just checking... still no dice

commit 966a1a40aa36732d9c2404b044a4ef63bd0bb417
Author: evanshultz <evanshu...@users.noreply.github.com>
Date:   Thu Apr 19 09:36:28 2018 -0700

    Delete Connector_Specialized.lib

commit aeb4270213da8a063f24163d6fa31e8521f08a83
Author: evanshultz <evanshu...@users.noreply.github.com>
Date:   Thu Apr 19 09:36:03 2018 -0700

    Delete Connector_Specialized.dcm

The top (latest) commit actually reverts the actions of the previous 
two commits. So now I have the idea that there's some sort of 
disagreement whether these files should be part of the repo or not. 
But I still have no idea why.


In a previous job I was the poor sod (or arrogant bastard, take your 
pick) who had to review commits before they were merged into the 
master branch. I would have rejected commits like these immediately. 
With Open Source development there's often less control over what gets 
merged and what doesn't. But that just means it's all the more 
important for everyone to make an effort to write good commit comments.


From the KiCad source file 
Documentation/development/commit-message-format.md:


Commit messages should begin with a subject line; try to limit
this to no more
than 50-72 characters. The body of the message should be separated
from the
subject by a blank line and wrapped at 72 characters. The body of
a commit
message should explain what the commit does and why, but do not
explain *how*
as the code itself should do that.




___
Mailing list: https://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] A reminder on Git commit comments

[Rene Pöschl]

Most of our contributors have no previous experience with git. So we 
really can not expect them to understand anything beyond the github 
workflow. (They are experts in electronics. Not IT) I also don't believe 
we should burden the contributors with too much with this.


This is even true for the maintainers. They are selected because they 
understand how to make good symbols and footprints. (Understanding of 
industry standards, limitations of manufacturing processes and the 
limitations of kicad)


For a lot of our casual contributors the current way of contributing is 
already too complex. I have seen a lot of them simply give up as soon as 
git did something they did not expect. This is especially common on the 
symbol lib side as it is likely that the contributor needs to do a 
manual merge because somebody else touched the same lib.


These casual contributions can in most cases be summarized as a single 
"added symbol for component x" message. The enduser might not be 
concerned on the detailed mistakes made by the contributor. (And if they 
are, the pull request is always linked to the contribution anyways.)
As we don't want users to hide their history from us maintainers (we 
want to see what they changed after feedback from us) we really do not 
want them to squash their commits (by using amend).


So the best solution might be to use the github squash merge feature 
instead of a normal merge and require the maintainer to write a good 
message about what changed. (Of course only if the contributor did not 
already make good commit messages.)



On 02/05/18 14:06, Wayne Stambaugh wrote:

This is why we have a commit message policy.  Obviously this isn't a
perfect solution.  Feel free to adopt this policy for library developer
commits.  There is always the hard line approach where you kick the
merge request back to the submitted and ask them to fix the commit
message or use `git commit --amend` to fix the commit message yourself.

On 5/1/2018 6:03 PM, Reece R. Pollack wrote:

I'd like to make an observation on some of the Git commit comments I'm
reading. Some of these commit log entries are really unhelpful.

When I was at University many, many years ago, students were taught to
place comments in their code. Many misunderstood the purpose of
comments, though, and would write code like this:

 x = x + 1;   /* Add 1 to x */


While the comment is totally correct, it's also totally useless. I can
/see/ that this line adds 1 to /x/; I don't need a comment to tell me
that. As a programmer coming along later, what I need to know is /why/ 1
is being added to /x/.

I'm seeing commit comments of the form "add one to x" in the KiCad
repos. These comments are useless. For an example, look at this commit
in the kicad-symbols repo:

 commit 4ada78e26774c841ce8ec33e8b221d04fed1f4c7
 Author: Rene Pöschl <r.poes...@student.tugraz.at>
 Date:   Fri Apr 20 11:14:47 2018 +0200

 Remove Connector_Specialized files.

Great. I can /see/ that these files are being removed. That's obvious
from looking at the content of the commit. But there is no explanation
of why these files were deleted. Don't tell me that there was discussion
about this in email; even if that happened it's irrelevant. No one
should have to go chasing through an email archive hoping to understand
why a change was made. That's what the commit log entry is for.

I went back further in the Git logs for commits touching these files
hoping to find a more illuminating commit comment, but found nothing
helpful. In fact, I came across an earlier series of commits that are
even /less/ helpful:

 commit 467170586b106d00c4df185dc1683046e259b74c
 Author: evanshultz <evanshu...@users.noreply.github.com>
 Date:   Thu Apr 19 09:42:52 2018 -0700

 Just checking... still no dice

 commit 966a1a40aa36732d9c2404b044a4ef63bd0bb417
 Author: evanshultz <evanshu...@users.noreply.github.com>
 Date:   Thu Apr 19 09:36:28 2018 -0700

 Delete Connector_Specialized.lib

 commit aeb4270213da8a063f24163d6fa31e8521f08a83
 Author: evanshultz <evanshu...@users.noreply.github.com>
 Date:   Thu Apr 19 09:36:03 2018 -0700

 Delete Connector_Specialized.dcm

The top (latest) commit actually reverts the actions of the previous two
commits. So now I have the idea that there's some sort of disagreement
whether these files should be part of the repo or not. But I still have
no idea why.

In a previous job I was the poor sod (or arrogant bastard, take your
pick) who had to review commits before they were merged into the master
branch. I would have rejected commits like these immediately. With Open
Source development there's often less control over what gets merged and
what doesn't. But that just means it's all the more important for
everyone to make an effort to write good commit comments.

 From the KiCad source file
Documentation/development/commit-message-f

Re: [Kicad-developers] [RFC]: New non copper pad paste and mask clearances behavior

[Rene Pöschl]

This sounds like a reasonable solution for kicad 5 to me.
Thanks for taking care of it.

On 02/05/18 14:58, jp charras wrote:

Hi All,

Dick Hollenbeck ( who wrote a lot of code for Kicad) proposed to use global 
mask margin values only
for pad at least on a copper layer.

(I am thinking this is also what was expected by some of guys)

Attached, a patch to use global mask settings only for pads on copper layers to 
build the mask shape
(solder or paste layer) of the pad.

Therefore pads *only* on a solder or paste layer are no longer affected by 
global settings.
(The drawback is a change in the behavior of previous Pcbnew versions, but it 
should not impact a
lot of old boards or old footprints)

The change in code is very small.

I added a info message in dialogs, in the pad clearance setup sub-window to 
explain the purpose of
this setting.
This is perhaps the main problem, because a message in a dialog must be short, 
and yet understandable...
The info messages are not perfect.

Please, test it.



___
Mailing list: https://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] Fwd: Re: What are the smallest values for pad paste and mask clearances? Why can't polygon pads not use negative mask clearance?

[Rene Pöschl]

On 28/04/18 09:28, jp charras wrote:

For custom shaped pads, building a solder mask shape with a negative margin can 
create issues
(unpredictable shape for non convex polygons).
So it is not allowed.



One can set a negative margin in the footprint itself. This negative 
margin is then used for custom pads with the footprint as well.


I would guess that a project global negative value will also apply to 
custom pads. You might want to look into that. (It does not really make 
sense to disable this on only one point where you can set this value. If 
negative values can break something then it does not matter where they 
come from.)



___
Mailing list: https://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] A reminder on Git commit comments

[Rene Pöschl]

On 03/05/18 08:31, Carsten Schoenert wrote:

Hello Rene,

Am 02.05.2018 um 14:57 schrieb Rene Pöschl:

Most of our contributors have no previous experience with git. So we
really can not expect them to understand anything beyond the github
workflow. (They are experts in electronics. Not IT) I also don't believe
we should burden the contributors with too much with this.

that's unfortunately true for most of contributors or contributions no
matter what kind of software or project and that's a social challenge we
all need to deal with.


That's the difference you miss. Software engineers are at least 
interested in learning about version control systems. After all they can 
use that skill in their career. Electrical engineers typically do not 
use it. They also normally do not get into contact with it in their 
education. And source code is a lot easier to merge. Merging two 
different contributions to the same symbol lib is a nightmare.

This is even true for the maintainers. They are selected because they
understand how to make good symbols and footprints. (Understanding of
industry standards, limitations of manufacturing processes and the
limitations of kicad)

Reading this thread and following from time to time some library issue
on GitHub (only by reading) I see this point in another light. It's up
to the maintainers to get fulfilled the requirements of the project if
he is accepting a pull request.

I see long lists of pull request on GitHub for the libraries which, and
this list seems even to increase more over the last months which is a
good sign I think, which waiting a review from one of the people which
are allowed to do merge requests. OTOH I see also commit messages as
Reece has pointed out. So for me it looks like there are two problems
which interacting together.


Most of the open pull requests have been reviewed and a fix from the 
contributor size is necessary.



1. The maintainers (you mean above I assume), which are needed to make
QS on new or modified parts based on the library standards, are also
"only" volunteering by there free time and this brings long waiting
queues even for simply contributions. This shows a lack of available
human resources with a deep understanding what the given standards are
mean on technical work.


Again: typically your contribution is reviewed within a few days. But i 
can't remember even one contribution (by a casual contributor) that i 
could merge after the first review. (Even with the fact that we have 
test scripts that take care of a lot of things before we librarians come 
into play.) There is just too much to consider.

2. There are also some library maintaining people needed which know how
to do the technical git work right. And this means mostly you sometimes
have to leave the world of platforms like GitHub, GitLab etc if needed.
If you know what a git merge really is and how a GitHub PR is
technically working under the hood you are able to solve quickly
contributions which otherwise need to wait until someone with a better
technical understanding will provide something useful in the issue
tracker on GitHub. Over the time this can become a serious problem for a
project as people can get quickly frustrated and wont contributing in
future times.
I know the technicalities of git. But it doesn't help much if the thing 
you are working on is not really well suited to be handled by git. A 
good example is that from time to time the save algorithm (of kicad) 
seems to randomly change. (Insert whites-paces where they never where 
before, change the ordering of lines, ...)


Again we are not dealing with human created text files. Merging is not 
really possible so we loose a large part of what can be done with git. 
(So if you have someone who knows git and git only he can do exactly 
nothing. The person needs to be able to read kicad files.)



For a lot of our casual contributors the current way of contributing is
already too complex. I have seen a lot of them simply give up as soon as
git did something they did not expect. This is especially common on the
symbol lib side as it is likely that the contributor needs to do a
manual merge because somebody else touched the same lib.

Also this problem isn't new and is related to git can't handle big
rather complex text files well if two persons have changed such a file.
git was developed for source code not for handling large text based
files. In the end you will come to the conclusion that git isn't the
best tool here but it's also the best we have.
For me than the workflow heavily based direct on plain git isn't the
correct one.


I have for my self compiled a list of features required for any tool 
handling the official lib:

- We need some way of sharing the data (oviosly)
- We need some sort of staging area for users to commit changes for 
review (we use pull requests for this)
- We need a way to run automatic tests on the contribution (continued 
integration support within pull requests)

Re: [Kicad-developers] Symbol library editor functionality removed

[Rene Pöschl]

On 01/01/18 00:40, Andy Peters wrote:

Apropos of the recent discussion about problems with the ‘/‘ character in 
symbol names (https://lists.launchpad.net/kicad-developers/msg31705.html), I 
went to rename three problematic symbols in my library. I’m on the 24 Dec 2017 
nightly on macOS. (This is all in bug 
https://bugs.launchpad.net/kicad/+bug/1740717).

First and foremost: there has never been a straightforward way to rename a 
symbol in a library from within Kicad. (That is, not editing the library files 
in a text editor.)

Previously I could copy the symbol using the “Load Component from Current 
Library” command followed by the “Create new component from the current 
component” command. The latter command opens a dialog box asking for the name 
of the new component. Then the user can save the library, delete the old symbol 
(the old name) and then save again. That first save is probably not necessary, 
but it doesn’t hurt.

Now in the current (as of 24 Dec, anyway) builds, the “create new from current” 
command no longer exists. We now have right-click accessed context menus, which 
are fine. All of the libraries in the table are available, so one doesn’t have 
to select the active library. Instead, the hide/reveal triangles let the user 
see all parts in a library.

So from the context menu: There is “duplicate part,” which makes a clone of the 
selected part in the same library, right below the original, appending _0 (and 
incrementing) to the name of the part. There are “cut part” and “copy part” 
options, along with a “paste part” option, which allow the user to move a part 
from one library to another, or copy it to another library. __None of these 
commands give the user the option to rename the symbol!__

Also, the paste is rather hidden: one has to left-click to select the target 
library then right-click on the library name again to bring up a context menu 
which includes “paste item.” Ideally, the cut, copy and paste of the selected 
item should show up in the main menu’s Edit menu.

To sum up (feature request!):

a) symbol duplicate/cut/copy/paste commands should be accessed through the main 
Edit menu, not a context menu. Never create the copy with a default symbol 
name, always ask the user for a new name.

b) Add a symbol rename command.

In the footprint library editor, if you change the name of the footprint in the 
Footprint Properties dialog, when you go to :Save the footprint in the 
library,” you are asked to give the footprint a name.


I agree such a feature would be nice.

Until something like this is implemented you can rename the symbol by 
changing the value field. (press e while your mouse pointer is on top of 
the value field. One can not edit the value field within the field 
properties dialog.)


The same issue has also been raised over at the forum:

https://forum.kicad.info/t/what-happened-to-the-button-that-copies-a-part-to-a-new-name/8920


For the footprints, one is only asked about the new footprint name if 
one saves a footprint to an active lib. The save footprint to new lib 
dialog does not allow for selecting a footprint name. This would also be 
a nice feature. (Especially because at least in some versions it does 
not seem to be possible to add an empty lib to the fp-lib-table.)



___
Mailing list: https://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] No op-amps in symbol library?

[Rene Pöschl]

Single op amps differ too much. It is not really possible to create generic
symbols for these.

See: https://github.com/KiCad/kicad-library/pull/1114

Specialized symbols are in the linear lib. (In the lib for v5 they will
eventually be found in Amplifier_Operational. These have not yet been moved
over to the new repo.)

On 24 Dec 2017 6:57 pm, "Mark Haun"  wrote:

My apologies.  I found the generic dual/quad in Device, after searching
fruitlessly for 15 minutes, but not before sending that message...  No
singles though?

Mark

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

Re: [Kicad-developers] Libedit and Modedit Icons

[Rene Pöschl]

On 09/01/18 16:50, Wayne Stambaugh wrote:

I'm with Jose on the arrows.  If we are going to use them, please don't
make the all different colors.  I don't see how a blue left arrow versus
a magenta right arrow conveys any meaning to the user.



I like the idea of coloring them differently. For me this will give an 
additional way to distinguish the buttons. (Some of them have only the 
direction of the arrow as a difference. Which is easily overlooked.) I 
hope having different colors will make it easier for my brain to 
remember which button does what. (I can't tell you how often i clicked 
load symbol instead of update symbol while working on the reorganization 
of the official lib.)


Maybe there is a better way to communicate differences but if buttons 
look as similar as a lot of them currently do, adding differentiating 
colors might help.


___
Mailing list: https://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] Some thoughts on symbol remapping

[Rene Pöschl]

On 10/01/18 11:46, Matthijs Kooijman wrote:


A related question: How are the changes in library layout intended to be
handled, when combined with the remapping dialog? AFAIU the migration to
the new kicad-symbols repository also involves renaming a lot of
libraries (e.g. Connectors.lib -> Connectors_Generic.lib). If you
upgrade to this new library layout, the (v4) library list must also be
updated to match the new library names? Or is there some automatic
conversion for this?

When you're still running v4, this can be fixed by manually fixing the
library list with the new library names. But when running v5, the
library list can (AFAICS) no longer be edited, but it is also assumed to
be correct by the remap dialog (which it will not be, then). Or am I
missing something here?

This would also be a case where the fallback I suggested above could be
helpful, though I guess a more reliable method would be better here.

Gr.

Matthijs

This is not as easy as simply a one to one mapping. The connectors 
library has been split into 3 libs. Most other libs into even more. 
(Especially manufacturer specific libs.)
In reality the best option for old projects will be to have the v4 libs 
installed in addition to the new libraries.


If you really want to map your project over to the new lib, you might 
want to look at the rename.json file found in the repo. It should 
contain most mappings.


And there is another complication. A lot of symbols that had invisible 
power pins have been updated to split the power pins in a separate unit 
as visible pins. (Example: logic gate ics and op amps)




___
Mailing list: https://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] Some thoughts on symbol remapping

[Rene Pöschl]

On 10/01/18 19:54, Matthijs Kooijman wrote:

Hi Wayne,


If the remapping algorithm cannot find the exact library match which
is currently being used (and should be in the project library list or
the cache) to provide the symbol, then there is no way to determine
the correct library and therefore cannot be remapped.  It also means
that your schematic is already broken.  This is why you should not
skip the rescue feature.

I can't quite remember if I skipped the rescue dialog (quite possibly),
but I can imagine a user (such as me) would reason that there is no need
for rescueing symbols into a rescue library, since all symbols are
available in their newly set lib table.

The symbols in your legacy schematic are almost certainly not in the new
symbol library table given the recent changes to the symbol libraries.

I was under the impression that symbols mostly got moved around, and
only some of them got renamed, but perhaps that impression is wrong.

Very few symbols them selves have been renamed. We mainly moved them 
around to other libs.
I don't know exactly how the remapping would handle that case. But worst 
case you can switch over to the new lib using a kicad 4 release and do 
the remapping after you transferred over to the new lib. (Don't try to 
do both at once. There is just more that can go wrong that way.)


Be careful with libs that have symbols with invisible power pins in 
them. (logic libs) We eliminated these type of symbols and changed them 
to have a separate unit for the power pins. (Sadly ERC will not complain 
if you don't place the power unit down. So if you update to the new 
symbols and forget to manually place the power unit you will get a pcb 
that has ICs in there that are not connected to power.)



___
Mailing list: https://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] Future plans on the KiCad library releases?

[Rene Pöschl]

On 15/01/18 17:53, Carsten Schoenert wrote:

Am 15.01.2018 um 12:09 schrieb Rene Pöschl:
...

1. Is there some release time strategy planned?
Are there any release dates planned for the newly created repositories
and what are the planes for releasing updates of these.

The only discussion i know of was between me and oliver over at the
github repo for the download page:
https://github.com/KiCad/kicad.github.io/issues/15
There we suggested a monthly release. (We will start to tag all library
repos once a month) The "package" for the download site is currently
rebuild weekly.

Doing a release monthly is fast enough, even every two months would be
fully acceptable I think.


Faster releases motivate contributors.
Remember: Most contributors add new stuff. Bugfixes are mainly
done by the library team.


3. What are the plans for providing coherent library names and the
introducing new libraries?
In the release circle for KiCad 4 some libraries have been abandoned and
have been moved over to new libraries without a upgrade path. That had
produced some headaches for me as package maintainer due users have
complained (correctly) their projects didn't worked after the package
update. I worked around this by providing symlinks from the old library
name to the new library name if possible.
Please don't break existing user installations within one release circle!

We will try to limit such problems. But it might still happen that a
library will be split up into multiple libs if the library gets too large.
As the libs are seen as a separate package any way, users should already
be aware that updates might break stuff.

I would hardly consider to not to do this within the current stable
release circle of KiCad. At least as long some extra action on the user
side is needed to get all the libraries in correct inclusion order and
usage for the local work.
Adding new libraries isn't that problematic as they are just 'new'.
Removing a library is a thing that doesn't have to happen, never ever!


That is why it might be a good idea to uncouple the software and library
version cycle. If the lib has a separate cycle we can inform users over
changes more easily.

We could make some announcement if something like this happens, then
package maintainers can mark such packages as a "major" release. (Not
sure how this would be compatible to the date idea.)

Well, we need to talk *now* about such things, we all need a plan for
handling the lifetime of a stable release.

Some more information about the current plans and doings in the library
team would be a good thing! And please not only through the KiCad user
forum. Please use also the KiCad website and/or the new GitHub site for
the libraries you have created.


Not sure what you mean here. The new libs are not yet official. Once they
are we will make a blog post about them.


Maybe we could also have special dates where such changes are allowed.
(Example once or twice a year.)

I'd suggest to go now through the libraries and rethink the names of
them which may conflict in the future. For example I've seen a symbol
library for Zigee, which is a protocol (and no hardware), the underlying
stack is IEEE 802.15.4 which is bound to the physics. The referenced
hardware is from TI a C2250 as QFN package which is also used for
6LoWPAN based transmissions. So I would suggest to rename this to
IEEE_802154 or similar.


Believe me. No matter how long you think about the names you will never
find everything that you want to change at a later date. We discussed the
current new names for over half a year.


4. What about backward compatibility of the libraries?
I don't follow the development of KiCad in a regularly way and
especially not the development of the libraries, so maybe this question
is answered in another place already. What can be done if people who
need to stay on KiCad 4 (e.g. we can't provide KiCad 5 for Debian 8
(Jessie) aka Old-Stable).

The kicad 5 libs are not guaranteed to be compatible with kicad 4. For
example we now allow the use of rounded rectangle and polygon pads in
footprints which are not understood by kicad 4. (Currently this already
affects a few libs. The majority of libs is still compatible to kicad 4.
But as time goes on the number of incompatible libs will grow.)

I personally can live with this, for the future I would suggesting the
development is happen in a own branch and do some merging into a release
branch (prefixed v5?) after the libraries have been tested and reviewed
enough, this would also give the possibility to create a branch for the
old v4 versions if someone wants to maintain this. There never has to be
rushing some new shiny elements into a release without some enough
invest of testing. And like done in other projects a merge window with
clear rules will help to keep a high quality on releases.


The libs for version 4 still live in their old repos ;).

As far as i know, no further version 4 release is planned.

We have a

Re: [Kicad-developers] Future plans on the KiCad library releases?

[Rene Pöschl]

The version number is not the real question here.
We can tag the libs monthly to allow users more fine grained control 
over which

version they want to use.
One option to still have the release information is to add an additional tag
(with the kicad version) to the monthly release that coincides with a kicad
release.

Now comes the real question. If the library release is bound to the 
kicad release,

are we limited in what we can do on the library side?
This either results in a slow down of library development.
(We would need to limit the changes allowed during a stable release cycle.
Example no splitting of libs.)
Or if we do not limit it, users might be surprised that their setup 
suddenly
doesn't work any more. (As has happened with the last few version 4 
releases.)

After all they updated kicad from one minor release to the next.
(Why should they expect changes to the library?)

If we however decide to decouple the release cycles the users gain more 
flexibility.
They are in charge as to what they want to update and when they want do 
to it.
A user that does only want to get bug fixes might opt to keep the old 
lib version.
Whereas another user might want to update the lib more often than the 
release

cylce of kicad would allow.

To be clear, both use cases are possible even without a monthly packaged 
release.

(But they require a separation of library and program packages.)
The one where we allow an older lib with kicad does require that no 
installer
does force a library update. (Example: Not possible for fedora users 
right now.)
The later use-case is also possible without a monthly package. But it 
definitely

is easier with it. Without a monthly tag it would be significantly harder.

In my mind the best option in the long run would be a kicad internal library
update manager that allows the installation of a specific library version.
But such a feature is in the far future. Now the question is: Why not 
use the
linux package manager for this, until we have a solution that would also 
work

for other operating systems?


On 15/01/18 14:56, Wayne Stambaugh wrote:

I though we were using version tags on the library repos that matched
the kicad stable release version to ensure that packagers would be able
to provide the same libraries.  I don't want a situation where each
packager uses different commits from the library repos to create
packages.  I don't think the date idea suggested is going to be reliable.

On 1/15/2018 6:09 AM, Rene Pöschl wrote:

On 15/01/18 11:16, Carsten Schoenert wrote:

Hi,

as the packaging for Debian will change as well for the next KiCad
release I've some questions pointed to the contributors and admins of
the libraries to be able to prepare the needed package transitions as
also mentioned by Jean-Samuel.

1. Is there some release time strategy planned?
Are there any release dates planned for the newly created repositories
and what are the planes for releasing updates of these.

The only discussion i know of was between me and oliver over at the
github repo for the download page:
https://github.com/KiCad/kicad.github.io/issues/15
There we suggested a monthly release. (We will start to tag all library
repos once a month) The "package" for the download site is currently
rebuild weekly.

2. What are the planned version numbers?
As the libraries are changing regularly and these changes are
independent from some KiCad major version I guess the usage of the KiCad
version model isn't sufficient here. Most other project use here a date
as version. e.g 2018_01 or 2018-02-15

As we aim for a regular release cycle independent from the kicad cycle,
using a date as the version number would make sense to me.

3. What are the plans for providing coherent library names and the
introducing new libraries?
In the release circle for KiCad 4 some libraries have been abandoned and
have been moved over to new libraries without a upgrade path. That had
produced some headaches for me as package maintainer due users have
complained (correctly) their projects didn't worked after the package
update. I worked around this by providing symlinks from the old library
name to the new library name if possible.
Please don't break existing user installations within one release circle!

We will try to limit such problems. But it might still happen that a
library will be split up into multiple libs if the library gets too large.
As the libs are seen as a separate package any way, users should already
be aware that updates might break stuff.
We could make some announcement if something like this happens, then
package maintainers can mark such packages as a "major" release. (Not
sure how this would be compatible to the date idea.)

Maybe we could also have special dates where such changes are allowed.
(Example once or twice a year.)

4. What about backward compatibility of the libraries?
I don't follow the development of KiCad in a regularly way and
especially not the development of the

Re: [Kicad-developers] What is the difference between library file format version 2.4 and 2.3

[Rene Pöschl]

Thanks for the quick answer.
I now know what to look for if we need to revert the lib version for 
some of the official libs.


On 18/01/18 23:16, Maciej Suminski wrote:

Since version 2.4 libraries support long pin and pad names (longer than
4 characters), so they are 100% compatible with 2.3 as long as you do
not use these features.

Regards,
Orson

On 01/18/2018 11:11 PM, Rene Pöschl wrote:

".lib" files created or edited with a recent nightly build set the
header information to version 2.4.

What is the difference to the lib version used in kicad stable (version
2.3).

I can open 2.4 version libs using kicad stable. But kicad stable does
not display anything that is stored in the dcm file.

(If i then edit such a lib file with stable, it results in the loss of
the complete dcm file content.)


Is it possible to revert the file version in some manner if a file has
been updated to version 2.4 such that the lib can be used again in kicad
stable?


___
Mailing list: https://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] Future plans on the KiCad library releases?

[Rene Pöschl]

On 17/01/18 10:03, Carsten Schoenert wrote:

Some more information about the current plans and doings in the library
team would be a good thing! And please not only through the KiCad user
forum. Please use also the KiCad website and/or the new GitHub site for
the libraries you have created.

Not sure what you mean here. The new libs are not yet official. Once they
are we will make a blog post about them.

Well, it was (and is) difficult to follow what is happen on the side of
the libraries, at least this is my impression. Communication is motsly
done by the GitHub issue tracker (which I find horrible to use) and I
guess within the KiCad forum. That's o.k. so far. I just want to mention
it's not easy for new people and also for me as someone who is packaging
all that various stuff to get easy actual information about the work and
plans of the library people.

About 1.5 to 2 years ago there I started to work with KiCad most of the
time I have tried to research around the usage and modification on the
libraries. It's now much better but cut be even better. And that 'even
better' is just a small step in my eyes. Hopefully now it's a bit mor
clear what I've tried to say.


Issues are not ideal but they are the best tool we currently have.
The mailing list would not be the right place to discuss lib specific
topics as they are of no interest to the typical developer.
(They are of interest to users, lib maintainers and maybe packagers)
Getting user input is most easily done via the forum.

In the future we will make a short post on the mailing list if we
think a change does influence packagers. (If i remember correctly
oliver did that in the past as well. With the horrible search
function of the mailing list this is not easy to find out.)


...

Believe me. No matter how long you think about the names you will never
find everything that you want to change at a later date. We discussed the
current new names for over half a year.

I think I know what you say and I don't want to blame anyone here. I
just want to bring the problems on top probably not only I've found.

What me often helps in such situations is to really try to look at
myself and my work like other would do. So, how does this all looks for
someone from outside? What would he expect to see or to find. Is the
work or the goal I try to get really useful for other people?

I know that is difficult but if it would be easy others would already
have done the work.

To get others peoples view they need to know that some feedback is
appropriated. And this brings the circle again to the communication.


We had an issue about this open for half a year.
We made regular inquires over at the info forum
where a lot of experienced users where asked for feedback.

And still some things have been missed.
Also a few manufacturers have already merged/changed name
since we defined our new lib setup.
(Microchip bought Atmel for example.)
This means that our MCU_Atmel* libs already required renaming.
(MCU libs are the only libs that include a manufacturer name.
For footprints it is worse because we allow manufacturer specific
footprints. These then include the manufacturer name in their name.)



...

The libs for version 4 still live in their old repos ;).

As far as i know, no further version 4 release is planned.

We have already archived most of the old repos.

What ever that means in times of git. :-)
But I got that you mean. And I suspect the core library team won't do
any maintenance of the old stuff proactive. But wanted to raise the
question as I know that some users of Debian can't follow the two years
release circle and need to stay on older versions and than ask mostly by
the bugtracker (in Debian) about new updates for their old versions. But
I can't answer such questions without to know what upstream is thinking
about. Maybe the library team want's write a small statement about the
situation of the libraries/symbols for the older version?


Kicad version 4 had one combined repo for symbols and 3d models
(kicad-library) plus one repo per footprint lib. (the 100 *.pretty repos)

Kicad version 5 has four repos:
 - kicad-symbols
 - kicad-footprints
 - kicad-packages3d (plus support repo kicad-packages3d-source)
 - kicad-templates




Another thing to consider:

It is hard to find what symbol/footprint is correct. Even if the contributor
states it worked for their project, a different pcb manufacturer might still
have problems with it. A symbol (or footprint) can be in the library for

years and nobody finds out that it is incorrect. (We found a few footprints

while reworking the libs, that where incorrect for the last 3 years.)

The library can not be compared to software in this regard.

I disagree on that as from the source view there is no difference
between both. But yes, one (or even more) person(s) can't do here any
serious quality testing work due the current and increasing amount of
symbols. This can only be done by automatic testing and as the 

Re: [Kicad-developers] [PATCH] Don't draw invisible pins in component chooser

[Rene Pöschl]

On 15/01/18 10:00, Maciej Sumiński wrote:

Perhaps we should have an ERC rule
that warns about invisible pins being connected to a wire, any thoughts?


Invisible pins are used for three distinct applications.

The first one is to remove clutter by hiding pins that should not be
connected. ERC will complain if you connect such pins if they have the
electrical type "Not connected".

The second application is to create "power labels". A invisible power
input pin is handled as a global label. These pins are meant to be
connected.

The third application is again to remove clutter by stacking pins. Here
you have one visible pin and several other invisible pins at the same
location. (Normally all these pins have the same name and electrical
type. With the exception of power input pins, power output pins and
output pins.)
Such pins are again meant to be connected.

This means a ERC rule that complains about connecting hidden pins will
create too many false positives. Having a lot of false positives means
users will start to ignore ERC output.

It might be a good idea to have a symbol checker that complains if
invisible pins are used differently than i described above.
In other words: complain for invisible pins if they are not part of a
stack or of types NC or power input.



___
Mailing list: https://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] Future plans on the KiCad library releases?

[Rene Pöschl]

On 15/01/18 11:16, Carsten Schoenert wrote:

Hi,

as the packaging for Debian will change as well for the next KiCad
release I've some questions pointed to the contributors and admins of
the libraries to be able to prepare the needed package transitions as
also mentioned by Jean-Samuel.

1. Is there some release time strategy planned?
Are there any release dates planned for the newly created repositories
and what are the planes for releasing updates of these.
The only discussion i know of was between me and oliver over at the 
github repo for the download page: 
https://github.com/KiCad/kicad.github.io/issues/15
There we suggested a monthly release. (We will start to tag all library 
repos once a month) The "package" for the download site is currently 
rebuild weekly.

2. What are the planned version numbers?
As the libraries are changing regularly and these changes are
independent from some KiCad major version I guess the usage of the KiCad
version model isn't sufficient here. Most other project use here a date
as version. e.g 2018_01 or 2018-02-15
As we aim for a regular release cycle independent from the kicad cycle, 
using a date as the version number would make sense to me.

3. What are the plans for providing coherent library names and the
introducing new libraries?
In the release circle for KiCad 4 some libraries have been abandoned and
have been moved over to new libraries without a upgrade path. That had
produced some headaches for me as package maintainer due users have
complained (correctly) their projects didn't worked after the package
update. I worked around this by providing symlinks from the old library
name to the new library name if possible.
Please don't break existing user installations within one release circle!
We will try to limit such problems. But it might still happen that a 
library will be split up into multiple libs if the library gets too large.
As the libs are seen as a separate package any way, users should already 
be aware that updates might break stuff.
We could make some announcement if something like this happens, then 
package maintainers can mark such packages as a "major" release. (Not 
sure how this would be compatible to the date idea.)


Maybe we could also have special dates where such changes are allowed. 
(Example once or twice a year.)

4. What about backward compatibility of the libraries?
I don't follow the development of KiCad in a regularly way and
especially not the development of the libraries, so maybe this question
is answered in another place already. What can be done if people who
need to stay on KiCad 4 (e.g. we can't provide KiCad 5 for Debian 8
(Jessie) aka Old-Stable).
The kicad 5 libs are not guaranteed to be compatible with kicad 4. For 
example we now allow the use of rounded rectangle and polygon pads in 
footprints which are not understood by kicad 4. (Currently this already 
affects a few libs. The majority of libs is still compatible to kicad 4. 
But as time goes on the number of incompatible libs will grow.)


___
Mailing list: https://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] UI changes for 5.0?

[Rene Pöschl]

On 09/02/18 01:28, Wayne Stambaugh wrote:

Assuming this can be completed in a reasonable amount of time and it is
consistent then I'm fine with this going into v5.  This is just cosmetic
and isn't going to break anything.  I've got a few more patches to
review and some work of my own to finish up over the weekend so I would
like to create the v5 branch and tag rc1 over the weekend unless there
are any outstanding crash bugs that I missed.  We can do cosmetic stuff
right up to the stable release.



If you want to tag rc1 this weekend, should we tag the libs as well?

Should we limit changes to the lib from that point on until the final 
stable release or can we still make larger improvements in that 
timeframe? (For example there is the idea to add pin numbers for the 
mechanical mounting pins of connectors which would require renaming of 
footprints to allow better footprint filters.)




___
Mailing list: https://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/RFC] Footprint editor menu bar

[Rene Pöschl]

On 19/02/18 12:14, Jeff Young wrote:

The Open / List All button is much faster on all libraries than it used to be, 
and it’s a bit of a step-child to Search by Keyword and Select by Browser 
anyway.

So, I’m going to propose that we add a Library selection widget to New 
Footprint..., Export Library... and Save As... and otherwise abandon the active 
library concept.


If you remove the active library concept from the "list all" stuff then 
you might want to add a way to filter (by library) after that dialog 
opened.
The live filtering of the list all dialog is much more powerful then the 
filter by keyword button. (I personally never use the search by keyword 
feature as i in most cases know in what lib a footprint resides. 
Otherwise i can use search all without having an active lib.)


One use-case where filtering by a specific lib might be helpful is 
library maintenance. The maintainer might have multiple different 
versions of the same lib in their system. (I have three copies of the 
footprint library added to my review project. Differentiated by a prefix 
to the library nickname. Results in >300 libs active in this project.)


The save button should also have a way to remember in which lib the 
currently edited footprint resides and offer a one click save. (Fill out 
the target lib and footprint name such that by default the current 
footprint is overwritten.)
The use-case for "i want to edit a footprint" is much more common then 
"i want to copy a footprint to a different lib/name". (At least for me.)


A bonus would be if the selection of the target lib is made easy via 
some live filtering option. (The official lib already has >100 footprint 
libs)


And please do not remove the lib browser! This is the only way of 
checking a large number of footprints in a fast way. This feature has 
already been removed for symbols. (By removing the symbol selector with 
the preview.) Don't make the same mistake on the footprint side.


___
Mailing list: https://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/RFC] Footprint editor menu bar

[Rene Pöschl]

On 19/02/18 13:16, Jeff Young wrote:

Hi Rene,

Comments in-line:


On 19 Feb 2018, at 12:07, Rene Pöschl <poesc...@gmail.com> wrote:

On 19/02/18 12:14, Jeff Young wrote:

The Open / List All button is much faster on all libraries than it used to be, 
and it’s a bit of a step-child to Search by Keyword and Select by Browser 
anyway.

So, I’m going to propose that we add a Library selection widget to New 
Footprint..., Export Library... and Save As... and otherwise abandon the active 
library concept.

If you remove the active library concept from the "list all" stuff then you 
might want to add a way to filter (by library) after that dialog opened.
The live filtering of the list all dialog is much more powerful then the filter 
by keyword button. (I personally never use the search by keyword feature as i 
in most cases know in what lib a footprint resides. Otherwise i can use search 
all without having an active lib.)

I have no issue against this in principal, but why not just use the Select by 
Browser then?  It’s not only got the by-library organisation, but it has better 
filtering across libraries, and it shows nice images.

Hmmm… I suppose the Browser is missing the Filter option….


For both the lib and footprint ;) (See next point)



One use-case where filtering by a specific lib might be helpful is library 
maintenance. The maintainer might have multiple different versions of the same lib 
in their system. (I have three copies of the footprint library added to my review 
project. Differentiated by a prefix to the library nickname. Results in >300 
libs active in this project.)

The save button should also have a way to remember in which lib the currently 
edited footprint resides and offer a one click save. (Fill out the target lib 
and footprint name such that by default the current footprint is overwritten.)
The use-case for "i want to edit a footprint" is much more common then "i want to 
copy a footprint to a different lib/name". (At least for me.)

Indeed, that’s the root motivation behind getting rid of the active library 
concept.


To clarify: i use the select active lib dialog to filter the lib name 
(it has live filtering of library names which the footprint browser 
lacks) This allows me to reduce the set of libs from >300 to ~3 in most 
cases. (example entering JST results in a list of the 3 different 
versions of the Connector_JST lib i have on my system. For a normal user 
it would result in one lib.)


After that, the list all dialog allows filtering for footprints (in the 
active lib)
To continue the JST example: Entering 1x02 will lists all JST single row 
connectors with two pins. (If either filtering option is missing, this 
use-case becomes a lot harder.)

A bonus would be if the selection of the target lib is made easy via some live 
filtering option. (The official lib already has >100 footprint libs)

And please do not remove the lib browser! This is the only way of checking a 
large number of footprints in a fast way. This feature has already been removed 
for symbols. (By removing the symbol selector with the preview.) Don't make the 
same mistake on the footprint side.

Could you say more about this?  Do you mean the Footprints view in the Symbol 
Selector?  (You can re-enable that through preferences.)  Or something else?

Cheers,
Jeff.

I fear this might be considered derailing the conversation. (It has 
currently nothing to do with footprints.) I just miss a way to browse 
symbols in a fast manner (use the arrow keys to see a preview of many 
symbols in a short amount of time)


This has been previously provided by the select symbol dialog in the 
symbol editor. (To emulate this behavior in the tree view, one would 
need a way to filter the available symbol libs and a way to navigate 
symbols in that lib by using arrow keys. Plus fast symbol preview 
without further user action.)



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

[Rene Pöschl]

On 25/02/18 23:29, Wayne Stambaugh wrote:

Stephen,

I would say that you should pull from HEAD of each library.  This will
probably be acceptable up to the stable release.  At this point we will
have to tag each repo.  Are any of our library devs planning on doing
any major reorganization of the libraries between now and the stable
release?  If so, than we may want to tag the library repos for rc1.

Cheers,

Wayne



I asked a week or so ago if i should tag. Your response was that it is 
unnecessary. Otherwise i would have tagged the libs back then.

l
As i do not yet plan to ban major changes, i tagged the repos with 
"v5.0.0-rc1"


___
Mailing list: https://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] RFC: toolbar button support for action plugins

[Rene Pöschl]

One can however archive a repo. (We did that with all the old library 
repos.)


I am not sure if the automatic synchronization with the lauchpad code 
would still work for archived repos.


On 23/08/18 20:31, José Ignacio wrote:

Pull requests cannot be disabled on Github

On Thu, Aug 23, 2018 at 1:26 PM, Carsten Schoenert 
wrote:


Hello Wayne,

Am 23.08.18 um 20:01 schrieb Wayne Stambaugh:

We do not use github for kicad source development.  It is merely a
mirror for user convenience.  Please do not open any issues on github
for the kicad source mirror.

I'd suggest to disable all these kind of features on GitHub then and
mention this circumstance more in detail in the project description on GH.

--
Regards
Carsten Schoenert

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




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




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

[Rene Pöschl]

Is it planned to include a new version of the libraries as well?
Right now we ensure that the library is relatively stable so i think the 
improvements made since the v5 release can easily be included.
(We do not allow major changes that would break backward compatibility. 
My plan is to use this rule at least till after the 5.1 release. Maybe 
even until the new file format is well enough implemented to play around 
with it in the official library.)


On 27/08/18 21:38, Wayne Stambaugh wrote:

I would like to get the 5.0.1 release out by the end of September if at
all possible.  There are still a few open bug reports which need to be
fixed before we can release this so if you can fix any of the ones that
do not already have an assignee[1], any help would be appreciated.  My
goal is to have all of the bug reports closed by 9/15 and give the
package devs a few weeks before making the release announcement.

Cheers,

Wayne

[1]: https://launchpad.net/kicad/+milestone/5.0.1

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

[Rene Pöschl]

Right now we have no changes made that would break projects. (That is 
what i meant with "backwards compatibility" I know it is not quite the 
right term)


Also i thought the cache lib plus rescue dialog should take care of 
minor changes to symbols if the user does not want to update a symbol 
should it be changed.
It should not even be necessary as we do not allow changes to symbol pin 
numbers or positions. (Unless there was a mistake in the symbol.)


As we did not include any of the wrongly scaled or wrongly aligned 3d 
models in the version 5 library there is also no danger of damaging the 
3d rendering side. (There is a reason why the version 5 3d model library 
is a lot smaller compared to the version 4 3d model lib)


We do neither allow changing any library names nor do we change symbol, 
footprint or 3d model names unless the original name was wrong enough to 
be in danger of being confused with a part different to the one that the 
object really represents.


If you do not intend to include the library then i will lift the ban on 
major changes as it does not make any sense in that case to hold back. 
(The only reason would be to allow including bugfixes into future kicad 
bugfix releases. I would include updating to newer industry standards as 
bugfix. The later is the main work being continued on the footprint 
side. We simply where not done with it with the v5 release but it was 
not bad enough to postpone the release.)



On 28/08/18 18:30, Wayne Stambaugh wrote:

I would be careful with any library improvements during stable bug fix
releases, particularly for symbol and 3d model libraries which are
linked rather than embedded.  My preference would be to just use the
same libraries tagged for the 5.0.0 release to keep changes to user
designs to a minimum.  Users can always download the latest libraries if
they prefer the bleeding edge.

On 8/28/2018 12:18 PM, Rene Pöschl wrote:

Is it planned to include a new version of the libraries as well?
Right now we ensure that the library is relatively stable so i think the
improvements made since the v5 release can easily be included.
(We do not allow major changes that would break backward compatibility.
My plan is to use this rule at least till after the 5.1 release. Maybe
even until the new file format is well enough implemented to play around
with it in the official library.)

On 27/08/18 21:38, Wayne Stambaugh wrote:

I would like to get the 5.0.1 release out by the end of September if at
all possible.  There are still a few open bug reports which need to be
fixed before we can release this so if you can fix any of the ones that
do not already have an assignee[1], any help would be appreciated.  My
goal is to have all of the bug reports closed by 9/15 and give the
package devs a few weeks before making the release announcement.

Cheers,

Wayne

[1]: https://launchpad.net/kicad/+milestone/5.0.1

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

[Rene Pöschl]

Just to be sure i will ask the other librarians how strict they where 
with our policy. (Sadly on the symbol side git is not of much help so i 
really need to rely on their word. I will also make some manual checks.)


For the future we might think about getting check scripts developed that 
check for changes that would go too far. (To reduce the chance of human 
errors. Some maintainers might be tempted to include one small change 
that is slightly across the line. If this happens with enough frequency 
then the sum of all changes could be too much.)


On 28/08/18 19:16, Wayne Stambaugh wrote:

On 8/28/2018 12:48 PM, Rene Pöschl wrote:

Right now we have no changes made that would break projects. (That is
what i meant with "backwards compatibility" I know it is not quite the
right term)

Also i thought the cache lib plus rescue dialog should take care of
minor changes to symbols if the user does not want to update a symbol
should it be changed.

Yes, but I do not like depending on the cache.  It's too fragile.  Once
the new schematic file format is in place, this will no be an issue.
Until then, I prefer to error on the side of caution given the cache
issues we've had in the past.


It should not even be necessary as we do not allow changes to symbol pin
numbers or positions. (Unless there was a mistake in the symbol.)

As we did not include any of the wrongly scaled or wrongly aligned 3d
models in the version 5 library there is also no danger of damaging the
3d rendering side. (There is a reason why the version 5 3d model library
is a lot smaller compared to the version 4 3d model lib)

We do neither allow changing any library names nor do we change symbol,
footprint or 3d model names unless the original name was wrong enough to
be in danger of being confused with a part different to the one that the
object really represents.

If you do not intend to include the library then i will lift the ban on
major changes as it does not make any sense in that case to hold back.
(The only reason would be to allow including bugfixes into future kicad
bugfix releases. I would include updating to newer industry standards as
bugfix. The later is the main work being continued on the footprint
side. We simply where not done with it with the v5 release but it was
not bad enough to postpone the release.)

I didn't realize you were keeping tight control of the library commits.
  I'm fine with these changes being added to 5.0.1.  I would like to keep
the libraries relatively stable during the entire 5 stable series.  For
version 6, you can make whatever changes you see fit.



On 28/08/18 18:30, Wayne Stambaugh wrote:

I would be careful with any library improvements during stable bug fix
releases, particularly for symbol and 3d model libraries which are
linked rather than embedded.  My preference would be to just use the
same libraries tagged for the 5.0.0 release to keep changes to user
designs to a minimum.  Users can always download the latest libraries if
they prefer the bleeding edge.

On 8/28/2018 12:18 PM, Rene Pöschl wrote:

Is it planned to include a new version of the libraries as well?
Right now we ensure that the library is relatively stable so i think the
improvements made since the v5 release can easily be included.
(We do not allow major changes that would break backward compatibility.
My plan is to use this rule at least till after the 5.1 release. Maybe
even until the new file format is well enough implemented to play around
with it in the official library.)

On 27/08/18 21:38, Wayne Stambaugh wrote:

I would like to get the 5.0.1 release out by the end of September if at
all possible.  There are still a few open bug reports which need to be
fixed before we can release this so if you can fix any of the ones that
do not already have an assignee[1], any help would be appreciated.  My
goal is to have all of the bug reports closed by 9/15 and give the
package devs a few weeks before making the release announcement.

Cheers,

Wayne

[1]: https://launchpad.net/kicad/+milestone/5.0.1

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

Re: [Kicad-developers] Stable 5 release.

[Rene Pöschl]

The library repos should now all be tagged. (Github had some server 
problems so it all took quite some time. I hope nothing got damaged 
because of that.)


On 19/07/18 10:49, Nick Østergaard wrote:

This sounds good. Thank you.
Den tor. 19. jul. 2018 kl. 10.43 skrev Rene Pöschl :

On 18/07/18 19:59, Carsten Schoenert wrote:

Am 18.07.18 um 19:55 schrieb Rene Pöschl:

I'm traveling the whole Saturday and Sunday to Debian DebCamp and
DebConf in Taiwan and working on packaging kicad-packages3d on a laptop
is PITA. So I'd like to this at home on a more powerful machine at home
latest on Friday afternoon.

Thanks!


By the way when giving deadlines stating your timezone might be
required. As you did not state one i choose to use CET summer time ;)

Argh, yes, a damn phone call has interrupted me while writing ...
But yes, CEST is the timezone I currently live. :-)


But if everything goes to plan i will tag the libs in a few hours anyway
giving you guys ample time.

Thanks!


Sadly i worked too long yesterday so i have been too tired to fully
check the libs.

I also have one or two PRs open that i want to check if they are correct
as they would fix some more minor issues. (Not a holdup but if they are
ready i would like to include them.)


So i will create the tags today in the evening. (Thursday 23:59 CEST
plus or minus two hours) Sorry about the delay.


___
Mailing list: https://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] Stable 5 release.

[Rene Pöschl]

On 18/07/18 18:09, Carsten Schoenert wrote:

Hi,

Am 18.07.18 um 16:23 schrieb Nick Østergaard:

I probably didn't mention this clearly. It is also good for me if
everything is tagged on friday, I guess that is mostly about the libs,
as I will probably tag i18n and doc myself.

I'd like to see at least the packages3D repository is tagged latest on
Friday 11AM to 12PM so packagers could start here, the reason is simple ...


I am on vacation next week with no connectivity.

I'm traveling the whole Saturday and Sunday to Debian DebCamp and
DebConf in Taiwan and working on packaging kicad-packages3d on a laptop
is PITA. So I'd like to this at home on a more powerful machine at home
latest on Friday afternoon.

Thanks!



By the way when giving deadlines stating your timezone might be 
required. As you did not state one i choose to use CET summer time ;)



But if everything goes to plan i will tag the libs in a few hours anyway 
giving you guys ample time.



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

Re: [Kicad-developers] KiCad 5 release announcement update

[Rene Pöschl]

I just noticed you sometimes use opengl/cairo and sometimes modern to 
reference the "modern toolset".


On 22/07/18 18:44, Wayne Stambaugh wrote:

I just pushed the updated version of the v5 release announcement[1].
Please let me know if you find any missing features.

Cheers,

Wayne

[1]:
https://github.com/KiCad/kicad-website/blob/master/content/blog/release-5.0.0.adoc

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

[Rene Pöschl]

On 23/07/18 05:27, Mark Roszko wrote:

Is it because the installer exe is huge?

That's because the footprint libraries are now part of the installers
and they are absolutely massive. (4GB uncompressed)


The whole repo (including git history) only has ~90MB
If any libs are to blame then it will be the 3d models. (6.5 GB 
including git history)


the installed files look fine to me though? The kiface files would be
hundreds of megs themselves if they had debug symbols but they are at
"normal" levels.
On Sun, Jul 22, 2018 at 11:16 PM Seth Hillbrand  wrote:

Hi Devs-

I'm seeing some reports (lp:1783037) that indicate the Windows build may be 
compiled CMAKE_BUILD_TYPE=RelWithDebInfo instead of Release.

Can anyone confirm this?  Is there a reason to do this for Windows?

-Seth

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






___
Mailing list: https://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] Stable 5 release.

[Rene Pöschl]

On 18/07/18 19:59, Carsten Schoenert wrote:

Am 18.07.18 um 19:55 schrieb Rene Pöschl:

I'm traveling the whole Saturday and Sunday to Debian DebCamp and
DebConf in Taiwan and working on packaging kicad-packages3d on a laptop
is PITA. So I'd like to this at home on a more powerful machine at home
latest on Friday afternoon.

Thanks!


By the way when giving deadlines stating your timezone might be
required. As you did not state one i choose to use CET summer time ;)

Argh, yes, a damn phone call has interrupted me while writing ...
But yes, CEST is the timezone I currently live. :-)


But if everything goes to plan i will tag the libs in a few hours anyway
giving you guys ample time.

Thanks!



Sadly i worked too long yesterday so i have been too tired to fully 
check the libs.


I also have one or two PRs open that i want to check if they are correct 
as they would fix some more minor issues. (Not a holdup but if they are 
ready i would like to include them.)



So i will create the tags today in the evening. (Thursday 23:59 CEST 
plus or minus two hours) Sorry about the delay.



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

Re: [Kicad-developers] kicad version and install location

[Rene Pöschl]

I get the feeling there is a bit more panic than need be.

One of the reasons is that the v4 installer on windows did set operating 
system variables (environment variables) which can create problems when 
updating. So it might be a good idea for the v5 installer to clean up 
this mess. (or at least warn the user) These things should really be set 
in the kicad config files via the kicad main window -> preferences -> 
configure path. (If the reports on the forum are correct then 
environment variables overwrite the settings of that dialog. And as the 
v4 installer set them by default this can be a source of major confusion.)


Another reason for problems is that the sym lib table is created with a 
new install and points to v5 libs but the fp-lib-table will still point 
to the github v4 libraries. (The 3d models will be also from the v5 
libs. Resulting in a mixed setup.) So an option to clean up the 
fp-lib-table from within the installer or within kicad might help. Maybe 
a "reset to factory settings" button within the library managers? (With 
the warning that personal libs will need to be manually added after that 
operation.)
Or at least some info for the user that if v4 was installed previously 
the fp-lib-table needs updating. (Maybe a dialog with "do not show again 
tickmak" that tells the user that if they had v4 previosly they need to 
reset the fp-lib-table or they need to install the v4 lib and setup the 
sym-lib-table accordingly.)




On 14/07/18 06:13, Adam Wolf wrote:
What options do we have?  Anything beyond "postpone V5" or "wait for 
the next release"?


Could we rebrand the V5 release as a "technical preview" or something 
that is suitable for experts (and new users, actually) and make V5.1 V5?


Adam

On Fri, Jul 13, 2018, 10:10 PM Mark Roszko > wrote:


Wayne,

Guess going to suggest it should be a priority to version the config
into folders.

This is a user made chart on how to install kicad 5 which honestly is
silly it has to even exist lol

https://kicad-info.s3-us-west-2.amazonaws.com/original/2X/d/d6143659e9237fc358588bed761ef3e557454cde.png


On Wed, Jul 11, 2018 at 1:56 PM Wayne Stambaugh
mailto:stambau...@gmail.com>> wrote:
>
> Mark,
>
> I agree with you in principal but this would require some major
changes
> to KiCad internally to handle the configuration data the
"windows" way.
> I really do not want to push the stable 5 release back any
further than
> it already has been.  I'm open to trying to accomplish this as
part of
> the 5.1 release if we can implement it soon enough to get some
testing
> on it.
>
> Cheers,
>
> Wayne
>
> On 7/8/2018 12:19 AM, Adam Wolf wrote:
> > Let's postpone this discussion maybe until the 10th when Wayne
is back
> > at it.
> >
> > On Sat, Jul 7, 2018, 10:33 PM Mark Roszko
mailto:mark.ros...@gmail.com>
> > >>
wrote:
> >
> >     Hey guys,
> >
> >     So with 5.0 approaching theres something of an annoying
problem on
> >     windows (that many are complaining about). The install
location!
> >     Currently, even though you can install kicad into separate
folders if
> >     you wanted to, kicad still tries to write to the same
appdata folder!
> >
> >     Why would you want both the new and old? Because if you
want to tweak
> >     a old design, you don't want to risk opening it in newer
versions and
> >     having unforseen bugs. New designs sure, you really want
to use the
> >     latest and greatest, but the old is a risk not worth taking,
> >     especially in the commercial field ;)
> >
> >     Also there is a settings conflicts between 4.0 and 5.0
sharing appdata.
> >
> >     I've seen some kicad forum "workarounds" where they use
launcher
> >     scripts that set KICAD_CONFIG_HOME each time. While it
works, its
> >     completely against the windows way :3
> >
> >
> >     What I propose, is we patch KiCad a little to:
> >
> >     1. Write to appdata in a versioned manner (just minor and
maybe
> >     minor version)
> >     C:\Users\%USERNAME%\AppData\Local\kicad 4.0\
> >     C:\Users\%USERNAME%\AppData\Local\kicad 5.0\
> >     C:\Users\%USERNAME%\AppData\Local\kicad 6.0\
> >
> >     2. Potentially prompt the user on first-start to copy
settings.
> >     (Maybe? Might be too much work for the final 5.0)
> >
> >     Then we patch the installer to follow the convention of:
> >     C:\Program Files\KiCad 4.0\
> >     C:\Program Files\KiCad 5.0\
> >     C:\Program Files\KiCad 6.0\
> >
> >     This would do what every other CAD and IDE does on Windows
> >     (versioned installs).
> >
> >     But what if people 

Re: [Kicad-developers] kicad version and install location

[Rene Pöschl]

Another idea would be to provide a package with version 4 libs. That way 
users can work with the new v5 features but do not need to worry about 
updating libraries.


On 14/07/18 09:29, Rene Pöschl wrote:

I get the feeling there is a bit more panic than need be.

One of the reasons is that the v4 installer on windows did set operating
system variables (environment variables) which can create problems when
updating. So it might be a good idea for the v5 installer to clean up
this mess. (or at least warn the user) These things should really be set
in the kicad config files via the kicad main window -> preferences ->
configure path. (If the reports on the forum are correct then
environment variables overwrite the settings of that dialog. And as the
v4 installer set them by default this can be a source of major confusion.)

Another reason for problems is that the sym lib table is created with a
new install and points to v5 libs but the fp-lib-table will still point
to the github v4 libraries. (The 3d models will be also from the v5
libs. Resulting in a mixed setup.) So an option to clean up the
fp-lib-table from within the installer or within kicad might help. Maybe
a "reset to factory settings" button within the library managers? (With
the warning that personal libs will need to be manually added after that
operation.)
Or at least some info for the user that if v4 was installed previously
the fp-lib-table needs updating. (Maybe a dialog with "do not show again
tickmak" that tells the user that if they had v4 previosly they need to
reset the fp-lib-table or they need to install the v4 lib and setup the
sym-lib-table accordingly.)



On 14/07/18 06:13, Adam Wolf wrote:

What options do we have?  Anything beyond "postpone V5" or "wait for
the next release"?

Could we rebrand the V5 release as a "technical preview" or something
that is suitable for experts (and new users, actually) and make V5.1 V5?

Adam

On Fri, Jul 13, 2018, 10:10 PM Mark Roszko mailto:mark.ros...@gmail.com>> wrote:

 Wayne,

 Guess going to suggest it should be a priority to version the config
 into folders.

 This is a user made chart on how to install kicad 5 which honestly is
 silly it has to even exist lol
 
https://kicad-info.s3-us-west-2.amazonaws.com/original/2X/d/d6143659e9237fc358588bed761ef3e557454cde.png


 On Wed, Jul 11, 2018 at 1:56 PM Wayne Stambaugh
 mailto:stambau...@gmail.com>> wrote:
 >
 > Mark,
 >
 > I agree with you in principal but this would require some major
 changes
 > to KiCad internally to handle the configuration data the
 "windows" way.
 > I really do not want to push the stable 5 release back any
 further than
 > it already has been.  I'm open to trying to accomplish this as
 part of
 > the 5.1 release if we can implement it soon enough to get some
 testing
 > on it.
 >
 > Cheers,
 >
 > Wayne
 >
 > On 7/8/2018 12:19 AM, Adam Wolf wrote:
 > > Let's postpone this discussion maybe until the 10th when Wayne
 is back
 > > at it.
 > >
 > > On Sat, Jul 7, 2018, 10:33 PM Mark Roszko
 mailto:mark.ros...@gmail.com>
 > > <mailto:mark.ros...@gmail.com <mailto:mark.ros...@gmail.com>>>
 wrote:
 > >
 > >     Hey guys,
 > >
 > >     So with 5.0 approaching theres something of an annoying
 problem on
 > >     windows (that many are complaining about). The install
 location!
 > >     Currently, even though you can install kicad into separate
 folders if
 > >     you wanted to, kicad still tries to write to the same
 appdata folder!
 > >
 > >     Why would you want both the new and old? Because if you
 want to tweak
 > >     a old design, you don't want to risk opening it in newer
 versions and
 > >     having unforseen bugs. New designs sure, you really want
 to use the
 > >     latest and greatest, but the old is a risk not worth taking,
 > >     especially in the commercial field ;)
 > >
 > >     Also there is a settings conflicts between 4.0 and 5.0
 sharing appdata.
 > >
 > >     I've seen some kicad forum "workarounds" where they use
 launcher
 > >     scripts that set KICAD_CONFIG_HOME each time. While it
 works, its
 > >     completely against the windows way :3
 > >
 > >
 > >     What I propose, is we patch KiCad a little to:
 > >
 > >     1. Write to appdata in a versioned manner (just minor and
 maybe
 > >     minor version)
 > >     C:\Users\%USERNAME%\AppData\Local\kicad 4.0\
 &g

Re: [Kicad-developers] kicad version and install location

[Rene Pöschl]

This only helps users who never had system environment variables set. 
They overwrite the settings coming from the config folders. (So all 
default windows installation are not helped with this.)


On 16/07/18 16:16, Nick Østergaard wrote:

Why does this need to be so complicated?

I think we could just rename the kicad config folder created and
searched by kicad from "kicad" to "kicad5" and be happy in the 5.x
branches.
Den man. 16. jul. 2018 kl. 15.11 skrev Bob Gustafson :

There is a tool which allows developers to quickly switch between different 
versions of Ruby (and their associated gemsets).

Perhaps it could be used for KiCad? Or perhaps just some of RVM's ideas could 
be adapted for KiCad

https://rvm.io/


On 07/15/2018 09:52 AM, Adam Wolf wrote:

I guess the fact that environment variables are tricky to set for graphical 
applications for the Mac may be a blessing here :)

Should we try to package a macOS version that installs to /Applications/KiCad5 
and /Library/Application Support/kicad?

Adam

On Sun, Jul 15, 2018, 2:41 AM Eeli Kaikkonen  wrote:

There are some people in the user forum who have spent time with these v4->v5 
problems, including me and Rene. The consensus about the environment variables 
seems to be what Rene already said, that they should not (without explicit user 
intervention) be set for the system, but from KiCad itself. Nick confirmed that 
the current v5 installer won't set them by default. They are still a problem if 
they have been set by v4 installer.

su 15. heinäk. 2018 klo 5.04 Strontium (strnty...@gmail.com) kirjoitti:

I honestly think each major revision of KiCad should be considered a NEW
program, installs to a new place has its configuration and libraries all
in a new location.  Only Incremental updates 5.0 -> 5.1 should be
considered upgrades.


I agree. It's probable that many users will want to continue with v4 for old 
projects but v5 for new, and in the future the same thing will be true for v5 
vs. v6, because they break the file/project compatibility. But where the 
compatibility is kept it's more likely to be considered as just an upgrade.


Kicad configuration isn't complex or onerous so if a user wants to bring
a Kicad4 config into Kicad5 or 6 or whatever, then they do that
themselves, otherwise after install Kicad5 is a fresh blank sheet with
no relationship to anything that happened on the users computer in
Kicad4.  I am not familiar with the issues on Windows, but I would have
thought now this is mostly a packaging issue only??


I tried modifying the Windows installer, I only needed to replace some of "KiCad" strings 
with "KiCad5" and it can install v5 alongside v4 independently. The only problem is the 
configuration and the environment variables set by v4. They can be handled with a startup script. 
See https://forum.kicad.info/t/does-v5-have-to-overwrite-on-install/11282 for some details.


I also agree if it can't work this way now on Windows, then its all a
bit late for V5, but maybe V6 can consider itself a new program distinct
from V5.  This would also help with testing, because users could use V5
for daily work, but also easily install a V6 daily side by side.


All this could be done with the Windows installer, provided that a startup 
script would be offered.

To make this all, at least the startup script, as simple as possible I would 
suggest one (or three) small changes to KiCad (for 5.1, or even 5.0.1?). Add 
command line options --config=/path/to/config and --ignore-env-vars. The former 
is obvious and would override KICAD_CONFIG_HOME system environment variable. 
The latter would make KiCad ignore all system environment variables and use the 
current internal logic and the path settings UI instead. That way the old 
variables could be left for v4 and the newer versions would be completely 
independent if the command line switches were used. The command line switch for 
the config path would be mostly for convenience. In Windows starting a program 
with custom environment variables is tedious and error prone to write (see the 
above mentioned thread). Command line switches are much easier.

It could also be possible to make --ignore-env-vars=true by default. Sharing 
the environment variables would be a special case if the user wants that.

The general problem with using system environment variables is that they are 
good for situations when there's only one version of a program on the system, 
and/or several processes share the same variable values. Neither of them is 
true for parallel installations of KiCad.

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



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

Re: [Kicad-developers] Questions on 6.0 eeschema file format

[Rene Pöschl]

My guess would be maintainability.
Having some way of sharing parts of different symbols with each other 
makes it way easier to manage large libs. (Nobody would be forced to use 
these features but they can make live easier for library maintainers. We 
could then for example provide a single nmos graphic that is then used 
in all nmos symbols of the official lib. Reducing the work for both 
contributors and maintainers.)


On 16/07/18 16:24, Tomasz Wlostowski wrote:

On 16/07/18 16:04, Jeff Young wrote:

Thinking more about it, we could probably auto-convert existing aliases to 
inheritance when we read them in.

Why do we need any inheritance at all? My only guess is to make Kicad
even more hackerish and difficult to understand.

Tom

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




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

Re: [Kicad-developers] The version string in the master branch

[Rene Pöschl]

Why not just use the date at which the nightly was compiled?

So something like dev-snapshot--mm-dd_g23849572
This is sortable and it should confuse nobody.

On 24/07/18 23:58, Eeli Kaikkonen wrote:



ti 24. heinäk. 2018 klo 22.59 Wayne Stambaugh (stambau...@gmail.com 
) kirjoitti:


 5.1-dev will confuse the package version
sorting when 5.1.0 is released.


Why do development packages (nightly builds or self-compiled) need to 
be sorted with release builds?


The most misleading strings are in the window bar and in the About 
KiCad dialog, and those texts aren't sorted anyways. Can't they be 
different than package file names? Windows nightly build package names 
don't have the version, nor do the ubuntu nightly packages.


I'm fine with Simon's proposal but
users will be no less confused by 5.0.0-452-g23849572 than by
6.0.0-rc1-xxx-commithash.


Based on my experience with linux distros and applications for about 
20 years and as a former open source developer I would like to 
disagree. But I know it doesn't count... I just want this sorted out 
because people will be confused for the next couple of years, and we 
who answer questions in the user forum have to clarify the situation 
every time.


Eeli Kaikkonen


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




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

Re: [Kicad-developers] 5.0.1 release

[Rene Pöschl]

Hi,

I doubt we need to rename the lib. It might be better to declare it as 
deprecated (remove it from the default library table and place a note in 
the readme file)


A new library can definitely be created that is build around the ngspice 
features that come with version 5 (the pspice lib is quite old and not 
really build for that implementation)

The library name is best discussed over at github.

On 30/08/18 04:41, Evan Shultz wrote:
There is one library name I'm concerned about. See 
https://github.com/KiCad/kicad-symbols/issues/451#issuecomment-378701973. 
This would be a breaking change, but if it's important enough to 
change it's likely to only affect a small subset of all KiCad users.


It is "correct" to have a library with symbols for simulation named 
"pspice"? Should the library just be named "spice" or something more 
generic?


On Tue, Aug 28, 2018 at 11:07 AM Rene Pöschl <mailto:poesc...@gmail.com>> wrote:


Just to be sure i will ask the other librarians how strict they where
with our policy. (Sadly on the symbol side git is not of much help
so i
really need to rely on their word. I will also make some manual
checks.)

For the future we might think about getting check scripts
developed that
check for changes that would go too far. (To reduce the chance of
human
errors. Some maintainers might be tempted to include one small change
that is slightly across the line. If this happens with enough
frequency
then the sum of all changes could be too much.)

On 28/08/18 19:16, Wayne Stambaugh wrote:
    > On 8/28/2018 12:48 PM, Rene Pöschl wrote:
>> Right now we have no changes made that would break projects.
(That is
>> what i meant with "backwards compatibility" I know it is not
quite the
>> right term)
>>
>> Also i thought the cache lib plus rescue dialog should take care of
>> minor changes to symbols if the user does not want to update a
symbol
>> should it be changed.
> Yes, but I do not like depending on the cache.  It's too
fragile.  Once
> the new schematic file format is in place, this will no be an issue.
> Until then, I prefer to error on the side of caution given the cache
> issues we've had in the past.
>
>> It should not even be necessary as we do not allow changes to
symbol pin
>> numbers or positions. (Unless there was a mistake in the symbol.)
>>
>> As we did not include any of the wrongly scaled or wrongly
aligned 3d
>> models in the version 5 library there is also no danger of
damaging the
>> 3d rendering side. (There is a reason why the version 5 3d
model library
>> is a lot smaller compared to the version 4 3d model lib)
>>
>> We do neither allow changing any library names nor do we change
symbol,
>> footprint or 3d model names unless the original name was wrong
enough to
>> be in danger of being confused with a part different to the one
that the
>> object really represents.
>>
>> If you do not intend to include the library then i will lift
the ban on
>> major changes as it does not make any sense in that case to
hold back.
>> (The only reason would be to allow including bugfixes into
future kicad
>> bugfix releases. I would include updating to newer industry
standards as
>> bugfix. The later is the main work being continued on the footprint
>> side. We simply where not done with it with the v5 release but
it was
>> not bad enough to postpone the release.)
> I didn't realize you were keeping tight control of the library
commits.
>   I'm fine with these changes being added to 5.0.1. I would like
to keep
> the libraries relatively stable during the entire 5 stable
series.  For
> version 6, you can make whatever changes you see fit.
>
>>
>> On 28/08/18 18:30, Wayne Stambaugh wrote:
>>> I would be careful with any library improvements during stable
bug fix
>>> releases, particularly for symbol and 3d model libraries which are
>>> linked rather than embedded.  My preference would be to just
use the
>>> same libraries tagged for the 5.0.0 release to keep changes to
user
>>> designs to a minimum.  Users can always download the latest
libraries if
>>> they prefer the bleeding edge.
>>>
>>> On 8/28/2018 12:18 PM, Rene Pöschl wrote:
>>>> Is it planned to include a new version of the libraries as well?
>>>> Right now we ensure that the library is relatively stable so
i think the
>>>

Re: [Kicad-developers] Round trace bends

[Rene Pöschl]

Hi,

right now there is a discussion ongoing on the forum about that. Might 
have some useful information for you in there:

https://forum.kicad.info/t/status-on-curved-smooth-corners-in-traces/12287

On 31/08/18 09:14, Martin Laabs wrote:

Hi,

is there is any development for chamfer trace edges ongoing? I use KiCAD
frequently for RF designs and strongly miss the functionality to change
45°/90° bends to round ones.
If there is no development planned I would try it on my own or try to find
a student implementing it for us.

Thank you,
   Martin Laabs

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




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

Re: [Kicad-developers] [RFC] New pad primitive shape: Chamfered roundrectangle

[Rene Pöschl]

Hi,

From reading the patch it seems this is for cases where you have 
exactly one corner to chamfer. Which is a nice addition for qfn footprints.


It would however be a bit more flexible if every corner is toggleable 
independently (so one could make pads with 1,2,3 or even 4 corners 
chamfered.)
That would allow this pad to also be used as paste only pad for exposed 
pads with thermal vias if one wants to avoid placing paste over vias.


On 30/08/18 20:33, jp charras wrote:

Hi Alls,

Attached a patch (against latest master version) that add a new pad
shape:  chamfered round rectangle.

It is now frequently used in footprints.

Although this kind of pad shape can be created by custom pad shapes, a
primitive pad shape has some advantages:
- more easy to edit
- support of thermal reliefs.

This is a feature especially for our library maintainers.

Please test.
Thanks.



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

[Rene Pöschl]

Strange i made the tag via the github web interface.

2018-07-04 17:45 GMT+01:00 Nick Østergaard :

> Hello Rene
>
> It looks like you didn't push the tag on templates, but I will just tag it
> then.
>
> Nick
>
> Den søn. 1. jul. 2018 kl. 00.34 skrev Rene Pöschl :
>
>> template repo is now tagged (sorry forgot about that one)
>>
>> On 30/06/18 23:56, Steven A. Falco wrote:
>> > Thank you!
>> >
>> > There are three repos not yet tagged with rc3 on github - two are
>> probably awaiting translation work: kicad-doc and kicad-i18n.  Also not
>> tagged: kicad-templates.  Once everything catches up to rc3, I will push
>> them to Fedora Rawhide.
>> >
>> >   Steve
>> >
>> > On 06/30/2018 08:50 AM, Wayne Stambaugh wrote:
>> >> I will do this when I tag rc3.  I think I have done it for every
>> release tag.
>> >>
>> >> On 06/30/2018 08:28 AM, Steven A. Falco wrote:
>> >>> If possible, it would also be great if a tar file for -rc3 could be
>> uploaded to launchpad, analogous to what was done for -rc2.
>> >>>
>> >>> We do have an -rc2 build in the official Fedora Rawhide now, and I'm
>> ready to step that up to -rc3 once available.
>> >>>
>> >>>  Thanks,
>> >>>  Steve
>> >>>
>> >>> On 06/29/2018 10:15 PM, Adam Wolf wrote:
>> >>>> Folks, enjoy your vacations.  We've all earned them! :)
>> >>>>
>> >>>> Wayne, if you could please announce on the list when you tag rc3,
>> that
>> >>>> would be awesome.
>> >>>>
>> >>>> Thanks!
>> >>>>
>> >>>> Adam
>> >>>> On Fri, Jun 29, 2018 at 7:27 PM Rene Pöschl 
>> wrote:
>> >>>>> What a coincidence. I will also be out of town for the next one and
>> a
>> >>>>> half weeks.
>> >>>>> As i can not guarantee that i will have internet access during this
>> time
>> >>>>> it might be necessary that somebody else tags the final kicad 5
>> library
>> >>>>> release.
>> >>>>> (I should be back at June the 10th late at night CET.)
>> >>>>>
>> >>>>> So i would suggest you make an issue one or two days before the
>> intended
>> >>>>> release date to notify the library team. (I already made one to warn
>> >>>>> them about this fact. See:
>> >>>>> https://github.com/KiCad/kicad-symbols/issues/712)
>> >>>>>
>> >>>>> On 30/06/18 01:59, Wayne Stambaugh wrote:
>> >>>>>> I think we are good to go with rc3.  I'm going to tag it tomorrow
>> unless
>> >>>>>> something comes up between now and then.  Once rc3 is tagged, I
>> would
>> >>>>>> like to hold off on any commits that are not critical bug fixes.
>> Since
>> >>>>>> I will be out of the country all next week for vacation, this will
>> give
>> >>>>>> users time to test rc3 builds.  If no critical issues arise during
>> this
>> >>>>>> week, I will tag 5.0.0 when I get back.  If this is an issue for
>> our
>> >>>>>> doc, library, or translation devs, please let me know.  Once our
>> 5.0.0
>> >>>>>> builds are ready to go, I will make the stable release
>> announcement and
>> >>>>>> proceed directly to the pub to celebrate.  We are getting close.
>> Thanks
>> >>>>>> again for all of your 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
&g

Re: [Kicad-developers] Stable 5 release.

[Rene Pöschl]

Sadly the old symbols are completely unusable in many modern circuits 
which use more then one power supply for different parts of the circuit. 
Hidden power pins are not the way to go! The fix for this bug must come 
from a different side then reintroducing hidden power pins.


On 12/07/18 13:46, Wayne Stambaugh wrote:

Rene,

Bug https://bugs.launchpad.net/kicad/+bug/1781290 may be an issue.  The
decision to separate symbol power pins as a separate symbol unit caused
this bug.  I didn't think about this when the changes to the symbol
libraries where made but it is going to cause issues for anyone trying
to create simulations.  I preferred the old symbols but it's not
something I feel strongly about but given that these changes caused this
issue we may need to rethink this decision or provide alternative
symbols for spice simulation.

Cheers,

Wayne

On 7/12/2018 5:36 AM, Rene Pöschl wrote:

The libs should be ready to go. We might still fix some minor things
till the release but we do not have any showstopper topics open.

On 11/07/18 20:49, Wayne Stambaugh wrote:

Are there any critical bugs remaining to be fixed for the stable 5
release?  I didn't see any thing outstanding but I may have missed
something while I was on vacation.  I'm going to create a 5.0.0
milestone for the last few remaining bugs and shoot for a 7/20 tag date
unless there are any more critical bugs lurking about.  I will also
create 5.0 and 5.1 branches.  If I tag on 7/20, I would like to make the
release announcement on 7/27.  Does anyone see any issues with these
dates

How do stand with our installers?  I saw the macos installer was making
some nice progress.

Are the doc devs, library devs, and translators (except for the recent
minor string changes) ready?

Is there anything else I'm missing?  I really would like to make these
dates.  I have an Olimex TERES laptop kit that I've been dying to play
around with but I know once I start on that, everything else will get
pushed to the back burner so I'm not going to start until version 5 is
released. :)

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] Stable 5 release.

[Rene Pöschl]

The libs should be ready to go. We might still fix some minor things 
till the release but we do not have any showstopper topics open.


On 11/07/18 20:49, Wayne Stambaugh wrote:

Are there any critical bugs remaining to be fixed for the stable 5
release?  I didn't see any thing outstanding but I may have missed
something while I was on vacation.  I'm going to create a 5.0.0
milestone for the last few remaining bugs and shoot for a 7/20 tag date
unless there are any more critical bugs lurking about.  I will also
create 5.0 and 5.1 branches.  If I tag on 7/20, I would like to make the
release announcement on 7/27.  Does anyone see any issues with these dates

How do stand with our installers?  I saw the macos installer was making
some nice progress.

Are the doc devs, library devs, and translators (except for the recent
minor string changes) ready?

Is there anything else I'm missing?  I really would like to make these
dates.  I have an Olimex TERES laptop kit that I've been dying to play
around with but I know once I start on that, everything else will get
pushed to the back burner so I'm not going to start until version 5 is
released. :)

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

Re: [Kicad-developers] Stable 5 release.

[Rene Pöschl]

On 12/07/18 16:20, jp charras wrote:

Le 12/07/2018 à 16:04, Rene Pöschl a écrit :

Sadly the old symbols are completely unusable in many modern circuits which use 
more then one power
supply for different parts of the circuit. Hidden power pins are not the way to 
go! The fix for this
bug must come from a different side then reintroducing hidden power pins.

These pins can be visible instead of hidden, just visible power and common to 
all units.


How well defined is the behavior of kicad if multiple of these 
duplicated pins are connected to different nets? (Is the behavior what 
users would expect?)


And additionally: A schematic just looks bad if you have unconnected 
pins on some units. (How can a user explain these unconnected pins their 
boss?)
Having the power pins as a separate unit is the way most other EDA tools 
go. This allows users to have power on a separate sheet and if the 
symbols are well defined one can even overlay the power unit with one of 
the other units. (Making this solution the most flexible option.)


That ERC does not check for non placed units is a drawback. As others 
already noticed most complex parts already suffer from this deficiency. 
(I am not prepared to make a hotfix on the symbol side to temporarily 
hide that deficiency in a limited subset of symbols.)


___
Mailing list: https://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] Stable version 5 tagged.

[Rene Pöschl]

Now i am confused. Yesterday (or a bit before) you wrote something about 
the 20th of july.
I will look into tagging the library sometime tomorrow CET. (Too tired 
right now to check if everything is ok.)


On 13/07/18 16:15, Wayne Stambaugh wrote:

Queue up the Handel's "Hallelujah Chorus", the stable version 5 source
has been tagged and the source archive uploaded to Launchpad.  I see a
malted beverage in my immediate future.  Lets get the libraries, docs,
and translations tagged so our builders can start created release
packages.  Once most (all) of the packages are built, I will make the
official release announcement on the KiCad blog and the user forum.
Once again, I cannot thank all of you enough for your hard work and efforts.

I will create the 5.0 and 5.1 branches shortly.  Please refrain from
making any commits into the development branch until I create these
branches.  Also, keep in mind that bug fixes will have to be
cherry-picked from the development branch to the 5.0 and 5.1 branches so
it will be a bit of extra work to keep everything synced up.

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

Re: [Kicad-developers] KiCad 5 and the Github footprint wizard?

[Rene Pöschl]

On 07/03/18 17:09, Thomas Pointhuber wrote:

Hi,

at least in the nightly it is still possible to add GitHub libraries
using "Append with Wizard".

Will this change? Because when someone uses this feature, it only
references to the old legacy repositories, without a clue about that.


Regards, Thomas




Maybe a good solution would be to set it to local files by default and 
remove the default value from the entry field.
I don't think it would be wise to remove this feature all together as 
some users might use it for their personal libs. Some might even want to 
stay with the old libs.


A note about the fact that the official libs are no longer supplied via 
the github plugin might help as well. (There are a lot of tutorial out 
there that will suggest the use of the github plugin. This will not 
change just because v5 is released. So a hint in the GUI might at least 
help some to discover that this workflow is obsolete.


___
Mailing list: https://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] Why do current nightlies report that they are kicad 5.0.0-rc2?

[Rene Pöschl]

Hello

It seems at least some packages of current nightlies report themselves 
as version 5.0.0-rc2. (The arch package seems to be one of them.) Is it 
on purpose that every nightly between tagging rc1 and tagging rc2 is 
reported as rc2? (I assumed only the one commit tagged would be called 
5.0.0-rcx)



___
Mailing list: https://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] Resistor 2512 footprint [Kicad 4.07]

[Rene Pöschl]

There are completely new footprints for such devices. (In the v5 lib)

I think the resistor lib should even be compatible with kicad 4 (it has 
no part with complex pads in it). At least the footprint in question is 
compatible.


They are now script generated [1]. The dimensions for the pads are based 
on IPC recommendations.


The dimensions for the resistors come from different datasheets. (The 
respective datasheet is always listed in the description of the footprint)



[1] 
https://github.com/pointhi/kicad-footprint-generator/tree/master/scripts/SMD_chip_package_rlc-etc




On 04/04/18 02:00, hauptmech wrote:

You should be able to check the footprint just by looking at it in a
text editor or online. That will be faster than compiling Kicad.

https://github.com/KiCad/Resistors_SMD.pretty/blob/master/R_2512_HandSoldering.kicad_mod
https://github.com/KiCad/kicad-footprints/blob/master/Resistor_SMD.pretty/R_2512_6332Metric_Pad1.34x3.40mm_HandSolder.kicad_mod


On 4/04/18 09:56, Augusto Fraga Giachero wrote:

Sorry for the noise, I'll try to compile the Kicad 5 rc2 and check if
this issue persists in the new library.

Thanks,
Augusto Fraga Giachero.

Nick Østergaard writes:


The kicad-developers list is not really for detailed library discussions
like this. You may have better luck reporting the issue directly on
https://github.com/kicad/kicad-footprints/issues

I am not sure what the plan is, but I don't think the Librarians will
update the old footprints, all activity are done in the new repos.

http://kicad-pcb.org/post/kicad-official-libraries/

2018-04-03 23:33 GMT+02:00 Augusto Fraga Giachero :


Hi!

I've had a an unpleasant surprise with a 2512 (imperial) smd resistor
footprint (Resistors_SMD:R_2512_HandSoldering) available in the Kicad's
official library (shame on me for not checking the dimensions before
sending the gerbers). When our boards arrived we verified that the pads
of this footprint are too further apart, up to the point that the
resistor barely touches the pads.

I've looked on some datasheets and other sources and confirmed that this
footprint is out of the recommended dimensions
(http://www.resistorguide.com/resistor-sizes-and-packages/).

I've attached an image showing the dimensions from the website
above. The recommended dimensions for 2512 are a = 3.5mm, b = 1.6mm and
c = 3.8mm, while in the footprint available on Kicad a = 3.2mm, b =
2.7mm (no problems with this been wider as it is a hand soldering
variant) and c = 5.2mm.

Dim(mm) Average Kicad
a   3.5 3.2
b   1.6 2.7 (ok, hand soldering)
c   3.8 5.2 (too further apart)

I don't known if it is fixed in the new Kicad 5 libraries, but it would
be nice to be fixed in the legacy libraries as well. I can make the fix
if nobody have already made.

Thanks,
Augusto Fraga Giachero.


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

[Rene Pöschl]

On 03/04/18 19:59, Kevin Cozens wrote:

I am seeing a problem with CvPcb where it fails to show me any DIP package
options when I select a 7400 IC on a board. I need to file a report about
the problem.


What version of the lib have you installed?

Are the footprint and symbol libs from the same version?

What is the footprint filter of the symbol?

What are the filter settings in cvpcb?


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

Re: [Kicad-developers] What are the requirements for the courtyard layer polygon?

[Rene Pöschl]

On 17/04/18 13:28, jp charras wrote:

Le 17/04/2018 à 13:15, Rene Pöschl a écrit :

If i understand it correctly, kicad 5 will offer a check for courtyard 
violations.

Does this check come with requirements with regards to the courtyard layer?

In particular: Does the polygon that describes the courtyard need to be closed? 
If not how much
tolerance is allowed?

Are arcs and circles supported?


The courtyard area must be a closed polygon.

* The algo to build the courtyard from graphic items is the algo used to build 
the board outline
(for instance for the 3D viewer).

* arcs and circles supported (and converted to segments to build the polygon)
* the tolerance is currently hardcoded to 0.01mm




Thanks for the fast reply.

In that case we will try to limit arcs and circles in the official lib 
as much as possible as they make it hard to get a closed polygon.



___
Mailing list: https://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] What are the requirements for the courtyard layer polygon?

[Rene Pöschl]

If i understand it correctly, kicad 5 will offer a check for courtyard 
violations.


Does this check come with requirements with regards to the courtyard layer?

In particular: Does the polygon that describes the courtyard need to be 
closed? If not how much tolerance is allowed?


Are arcs and circles supported?


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

Re: [Kicad-developers] What are the requirements for the courtyard layer polygon?

[Rene Pöschl]

On 18/04/18 12:59, jp charras wrote:

Le 17/04/2018 à 13:54, Rene Pöschl a écrit :

On 17/04/18 13:28, jp charras wrote:

Le 17/04/2018 à 13:15, Rene Pöschl a écrit :

If i understand it correctly, kicad 5 will offer a check for courtyard 
violations.

Does this check come with requirements with regards to the courtyard layer?

In particular: Does the polygon that describes the courtyard need to be closed? 
If not how much
tolerance is allowed?

Are arcs and circles supported?


The courtyard area must be a closed polygon.

* The algo to build the courtyard from graphic items is the algo used to build 
the board outline
(for instance for the 3D viewer).

* arcs and circles supported (and converted to segments to build the polygon)
* the tolerance is currently hardcoded to 0.01mm



Thanks for the fast reply.

In that case we will try to limit arcs and circles in the official lib as much 
as possible as they
make it hard to get a closed polygon.

Circles do not create issues, because they are similar to a closed polygon.
We usually do not have issues with arcs of 90 and 180 deg, because if the 
center and the start point
are on the current grid, the ending point is also on the grid.


Thanks for the clarification. I will use this information when i adapt 
the KLC for it.



___
Mailing list: https://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] Lib maintainers request help for reviewing installation script changes

[Rene Pöschl]

Dear developers,

we lib maintainers might be good at checking symbols and footprints 
against datasheets, the KLC and industry standards but we are a bit lost 
with the requirements of installation scripts.


Could one of you take a look at the changes in the following pull requests?


- https://github.com/KiCad/kicad-packages3D/pull/284

- https://github.com/KiCad/kicad-symbols/pull/409

- https://github.com/KiCad/kicad-footprints/pull/450


___
Mailing list: https://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] Zone keepouts within modules

[Rene Pöschl]

On 19/03/18 13:02, Simon Santesteban wrote:

Hi everyone,

I am a new developer in kicad community. I have been working on adding
zones to modules, so I would like to share this work.
Find attached a patch to have this functionality.

Regards,

Simon


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



I think oliver walters did start with something similar but did not get 
it finished before the feature freeze.


I am not sure if he plans on continuing his work on this. (I fear his 
other responsibilities ensure that he has no time for it.)



The discussions about that might be useful for you.

https://www.mail-archive.com/kicad-developers@lists.launchpad.net/msg25847.html

https://www.mail-archive.com/kicad-developers@lists.launchpad.net/msg25674.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

Re: [Kicad-developers] MacOS Packaging Question

[Rene Pöschl]

On 03/03/18 23:32, Seth Hillbrand wrote:
​In the current nightly MacOS builds, we package the applications, 
symbols and 3d models but no footprints.


Is this an oversight?

-S​




This might be because in kicad 4 the footprints where downloaded on 
demand via the github plugin.
With the new library setup (single repository for all footprints) this 
is no longer possible.


I assume some packages for other operating systems might have a similar 
problem


___
Mailing list: https://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] PPA: KiCad 5.0

[Rene Pöschl]

On 26/02/18 10:53, Jean-Samuel Reynaud wrote:

Dear All,

  Following KiCad 5.0 tagging, I had create a dedicated PPA for next
release (5.0). For the moment, only RC1 of kicad is built. When other
repositories will be tagger (i18n, docs and all libs), I will also
provide them on this PPA.

It's available at:
https://launchpad.net/~js-reynaud/+archive/ubuntu/kicad-5

Daily build are still active and still building "master" branch of KiCad
as usual.

Regards,

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



The library repos have been tagged with 5.0.0-rc1

(As requested yesterday in a similar mailing list thread. [1])

This will not be the last tag for 5.0.0. We will make more bugfixes. If 
time permits we might also do some larger changes as well.


After the v5 release we will limit the lib to bugfixes and new 
additions. If a larger change is proposed we might create separate 
branches for v5 and v6



[1] https://lists.launchpad.net/kicad-developers/msg34367.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

Re: [Kicad-developers] 5.0.1 status

[Rene Pöschl]

Regarding libs.

I would need to run the script testing for incompatible changes with the 
current master. (I can do this as soon as i am home today. So in a few 
hours.) I already ran it at the end of August the changes that occurred 
until then are documented in [1]


As soon as i update that list somebody will need to decide if the 
changes are acceptable for being included. If not then 5.0.1 should 
continue to ship with the libs tagged as 5.0.0 (It would not make much 
sense to add a new tag onto the same commit. I would even argue that 
this might confuse users who would expect changes if a new tag is created.)


[1]: 
https://github.com/KiCad/kicad-symbols/issues/856#issuecomment-417592514


On 08/10/2018 15:24, Wayne Stambaugh wrote:

I'm making a last call for any bug fixes that need to made to the 5.0
branch for the 5.0.1 release.  Please let me know if you have any
pending fixes before I tag 5.0.1.  I intend to tag this around 6PM EST
unless I hear otherwise.  How much time will our translators and
librarians need to tag 5.0.1?  Hopefully not too long so we can give our
packagers time to get release packages built.  I would like to make the
release announcement this coming weekend if at all possible.

I also intend to leave the 5.0.1 tag as the revision and set the source
archive version to 5.0.1-unknown so the -dev suffix will no longer be in
play moving forward which should make our packagers happy.

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

Re: [Kicad-developers] Some of our symbols currently still have invisible power pins. We want to fix this but want to give you guys a chance for input first.

[Rene Pöschl]

Only logic family libs are affected. The 4xxx lib is already done. This 
leaves 4 libs at most. (I have no access to kicad right at this moment 
so i can not check.)


Only option 2 ends up with multiples of the lib. In option 3 we will 
rename the lib (meaning a new lib will be added and the original one is 
deleted)


On 06/11/18 23:24, Diego Herranz wrote:

Hi, Rene.

Thanks for bringing this up. I've never liked hidden power pins. In my 
opinion, the python philosophy applies here too: "Explicit is better 
than implicit."


How many libraries will need this?
I'm asking because, if we went for option 3 (or 2), will we end up 
with a lot of nearly identical duplicated libraries? That can be very 
confusing for users and for maintaining the GitHub libraries (e.g. 
getting pull requests for the old libraries instead of the new ones, 
etc.).
And at some point we would need to get rid of the old ones anyway not 
to carry them forever, won't we?


I'm wondering whether we can for option 1 if we evaluate what the 
behaviour would be regarding ERC, symbol rescue, etc.


Thanks,
Diego

On Tue, Nov 6, 2018 at 9:42 PM Rene Pöschl <mailto:poesc...@gmail.com>> wrote:


Hi all,


Sadly we did not come around to fix all symbols before the v5
release.
We now seem to have a volunteer who would be prepared to fix these
symbols.

There is a catch though. Whatever we do to fix this it will break
designs that use the old symbols right now.


So we have a few options:

- 1 - Change the symbols inside the library and inform the users
about
this fix. (Will break current designs as the power pins will no
longer
be connected automatically. This after all is the point of the
fix. Not
sure if rescue is reliable enought to chatch that. ERC might also not
complain if we put the power pins onto a separate unit.)

- 2 - Add a separate library that holds the fixed symbols, keep
the old
one but remove it from the template library table. This means no
designs
are borken as old users do not get the new lib added without an
explicit
action on their part.

- 3 - Rename the library before fixing it. add the new lib to the lib
table. This would still break designs. (But in a different way. In
this
case the symbol might simply not be found. This is something that the
rescue stuff should deal with.) In addition users will get an error
message when starting eeschema or the symbol editor that alerts them
about a missing file. (So if we make an announcement that includes
the
error message they should find it when they google for it.)


My personal vote would be for option 3.


___
Mailing list: https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
Post to     : kicad-developers@lists.launchpad.net
<mailto:kicad-developers@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-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] Some of our symbols currently still have invisible power pins. We want to fix this but want to give you guys a chance for input first.

[Rene Pöschl]

Hi all,


Sadly we did not come around to fix all symbols before the v5 release. 
We now seem to have a volunteer who would be prepared to fix these symbols.


There is a catch though. Whatever we do to fix this it will break 
designs that use the old symbols right now.



So we have a few options:

- 1 - Change the symbols inside the library and inform the users about 
this fix. (Will break current designs as the power pins will no longer 
be connected automatically. This after all is the point of the fix. Not 
sure if rescue is reliable enought to chatch that. ERC might also not 
complain if we put the power pins onto a separate unit.)


- 2 - Add a separate library that holds the fixed symbols, keep the old 
one but remove it from the template library table. This means no designs 
are borken as old users do not get the new lib added without an explicit 
action on their part.


- 3 - Rename the library before fixing it. add the new lib to the lib 
table. This would still break designs. (But in a different way. In this 
case the symbol might simply not be found. This is something that the 
rescue stuff should deal with.) In addition users will get an error 
message when starting eeschema or the symbol editor that alerts them 
about a missing file. (So if we make an announcement that includes the 
error message they should find it when they google for it.)



My personal vote would be for option 3.


___
Mailing list: https://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] Some of our symbols currently still have invisible power pins. We want to fix this but want to give you guys a chance for input first.

[Rene Pöschl]

On 07/11/18 17:39, Kevin Cozens wrote:ons I was thinking that option 3 
might be the best

How will not hiding pins affect IC's with multiple parts (e.g. a 7400)? Will
each part have the power and ground pins?


Like we did with the 4xxx series parts. There will be a further unit 
added that only holds the power pins. (Meaning the symbol will no longer 
be one where the units are interchangeable.)

Adding the power pins to every unit is confusing and error prone.

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

[Rene Pöschl]

Libraries are tagged.

On 09/10/18 00:24, Wayne Stambaugh wrote:

Rene,

Looks good to me.  Tag it as soon as you are ready.

Thanks,

Wayne

On 10/08/2018 04:45 PM, Rene Pöschl wrote:

Hi all,

Updated list can now be found in comment
https://github.com/KiCad/kicad-symbols/issues/856#issuecomment-427971380
(I tried to determine for every change where it comes from. Did not find
the pull request in question for the three removed symbols and for one
possible false positive.)



On 08/10/18 20:52, Wayne Stambaugh wrote:

Hi Rene,

I didn't see anything the the list you linked that I would consider a
show stopper.  I wait until you post the results of you test script
against the latest changes.

Thanks,

Wayne

On 10/8/2018 11:35 AM, Rene Pöschl wrote:

Regarding libs.

I would need to run the script testing for incompatible changes with the
current master. (I can do this as soon as i am home today. So in a few
hours.) I already ran it at the end of August the changes that occurred
until then are documented in [1]

As soon as i update that list somebody will need to decide if the
changes are acceptable for being included. If not then 5.0.1 should
continue to ship with the libs tagged as 5.0.0 (It would not make much
sense to add a new tag onto the same commit. I would even argue that
this might confuse users who would expect changes if a new tag is
created.)

[1]:
https://github.com/KiCad/kicad-symbols/issues/856#issuecomment-417592514

On 08/10/2018 15:24, Wayne Stambaugh wrote:

I'm making a last call for any bug fixes that need to made to the 5.0
branch for the 5.0.1 release.  Please let me know if you have any
pending fixes before I tag 5.0.1.  I intend to tag this around 6PM EST
unless I hear otherwise.  How much time will our translators and
librarians need to tag 5.0.1?  Hopefully not too long so we can give
our
packagers time to get release packages built.  I would like to make the
release announcement this coming weekend if at all possible.

I also intend to leave the 5.0.1 tag as the revision and set the source
archive version to 5.0.1-unknown so the -dev suffix will no longer
be in
play moving forward which should make our packagers happy.

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

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

[Rene Pöschl]

Hi all,

Updated list can now be found in comment 
https://github.com/KiCad/kicad-symbols/issues/856#issuecomment-427971380 
(I tried to determine for every change where it comes from. Did not find 
the pull request in question for the three removed symbols and for one 
possible false positive.)




On 08/10/18 20:52, Wayne Stambaugh wrote:

Hi Rene,

I didn't see anything the the list you linked that I would consider a
show stopper.  I wait until you post the results of you test script
against the latest changes.

Thanks,

Wayne

On 10/8/2018 11:35 AM, Rene Pöschl wrote:

Regarding libs.

I would need to run the script testing for incompatible changes with the
current master. (I can do this as soon as i am home today. So in a few
hours.) I already ran it at the end of August the changes that occurred
until then are documented in [1]

As soon as i update that list somebody will need to decide if the
changes are acceptable for being included. If not then 5.0.1 should
continue to ship with the libs tagged as 5.0.0 (It would not make much
sense to add a new tag onto the same commit. I would even argue that
this might confuse users who would expect changes if a new tag is created.)

[1]:
https://github.com/KiCad/kicad-symbols/issues/856#issuecomment-417592514

On 08/10/2018 15:24, Wayne Stambaugh wrote:

I'm making a last call for any bug fixes that need to made to the 5.0
branch for the 5.0.1 release.  Please let me know if you have any
pending fixes before I tag 5.0.1.  I intend to tag this around 6PM EST
unless I hear otherwise.  How much time will our translators and
librarians need to tag 5.0.1?  Hopefully not too long so we can give our
packagers time to get release packages built.  I would like to make the
release announcement this coming weekend if at all possible.

I also intend to leave the 5.0.1 tag as the revision and set the source
archive version to 5.0.1-unknown so the -dev suffix will no longer be in
play moving forward which should make our packagers happy.

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] Remind me why we have both filled polygons and non-copper zones

[Rene Pöschl]

Zones and polygons behave a bit differently when it comes to rounded 
corners.
For zones the minwidth setting controls the round radius, for polygons 
it is the line width.
This means polygons with rounded corners are always larger than drawn by 
the radius size (half line width). But zones are exactly as drawn 
(except around corners where they are rounded)


Additionally: zones have more editing support. (At least in 5.0.0 there 
is no way to add corners to polygons after it is first created. I assume 
this will be added at a later stage)


On 02/10/18 23:26, Seth Hillbrand wrote:

Hi Jeff-

Here's a relevant thread:
https://lists.launchpad.net/kicad-developers/msg34235.html

-S

Am Di., 2. Okt. 2018 um 05:16 Uhr schrieb Jeff Young >:


Was the intention that one of them was being replaced by the
other? Or do we need both for some reason?

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] Cost of different courtyard elements for the closed outline and DRC algorithms

[Rene Pöschl]

On 01/01/19 23:53, John Beard wrote:


@Rene: can you give some examples of "extensive" arc use on the
courtyard layers that you are thinking of?

Cheers,

John



The two pull requests i linked should give you an idea of what i right
now consider as most extensive use. Maybe also some battery holders that
are already in the lib.

Right now only parts that are used in low numbers on a board have
rounded courtyards. These are also the parts that benefit the most from
using close fitting courtyards. (A battery holder as a rectangle would
waste a lot more space than thinking about what to do with a 0402
(imperial) resistor.)

What i gather from this discussion is that we should be ok with using
arcs in such cases but we should not go overboard and do it for every
part. (Especially not ones where there is very little to gain.)


___
Mailing list: https://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] Cost of different courtyard elements for the closed outline and DRC algorithms

[Rene Pöschl]

Hi,

Right now we have a few contributions for the library that use arcs 
quite extensively on the courtyard layer.


I would therefore like a bit of input.

Are arc generally more expensive than lines?

Is there a difference if the arc is a multiple of 90 degree compared to 
any other angle.



Is there a difference if the endpoints of two neighboring endpoints meed 
exactly vs they being within the tolerance range for counting as a 
closed outline (If i remember correctly then the tolerance was 0.01mm. I 
assume this is the radius of the tolerance circle.)


Regarding tolerance: How stable will the currently chosen value be? (If 
we allow arcs on the courtyard layer then we will need to fix a 
tolerance in the KLC. This is especially the case for arcs that are not 
90 degrees.)



The two pull requests that are responsible for this question:

- https://github.com/KiCad/kicad-footprints/pull/1040

- https://github.com/KiCad/kicad-footprints/pull/1159


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

Re: [Kicad-developers] [RFC] Symbol library file format

[Rene Pöschl]

Something else that i remembered now.

Would it be a good idea to prepare for alternative function handling for 
pins?
Meaning an alternative pin name connected to an alternative type (or a 
number of these)


That would allow better symbols for micro controllers.

I do not expect this to be implemented for v6 but maybe this is 
something that should be integrated in the file format spec such that a 
future implementation is comparably easy.


On 01/01/19 20:59, Wayne Stambaugh wrote:

I have updated and published the symbol file format[1] for comment.
Hopefully there isn't too much to change.  The only thing to really
finalize is the internal units.  The initial concept was unitless but
the more I think about it and discuss with other developers, it makes
more sense to use units for the following reasons:

1. It's easier to visualize in your head how the symbols on a given page
size will layout.

2. Converting from other file formats (Eagle, Altium, etc) will be
easier since most if not all of them have a defined unit.

I'm thinking 10u (or possibly 100u) will make a good internal units
value.  Once we nail down the units, I will update the file format
document accordingly.

Please keep in mind that this is the symbol library file format document
so things like constraints belong in the schematic file format.  I will
be posting the schematic file format as soon as I finish updating it.

Cheers,

Wayne

[1]:
https://docs.google.com/document/d/1lyL_8FWZRouMkwqLiIt84rd2Htg4v1vz8_2MzRKHRkc/edit


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




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

Re: [Kicad-developers] [RFC] Symbol library file format

[Rene Pöschl]

On 04/01/19 15:10, Wayne Stambaugh wrote:

Is there a way to mark a unit as "power unit" (I think you mentioned
sometime back that this might be required to properly make simulation
for multi unit symbols possible while still allowing the power unit to
be separate. A power unit would also be a "must be placed unit" but i
feel separating these two might add more flexibility.)

See definition above.  I'm not sure having a "required" keyword is
useful.  Do you have an example in mind.



There are many parts that not only have power connections but also some 
control connections that are necessary for the function of the part. A 
lot of these have the control pins shared between many units so it makes 
sense to move them to a specialized unit. That unit would then be 
required but does not fulfill the "this is a power unit" thing. Hence my 
suggestion for a more general "this unit must be placed" vs. "This unit 
is optional" field. (The "This is a power unit" thing is not really 
necessary for ERC. At least not if there is a "this is a required unit" 
flag. The only reason i suggested that is because you mentioned that it 
might be required for simulation purposes.)


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

Re: [Kicad-developers] [RFC] Symbol library file format

[Rene Pöschl]

I have a few questions regarding multi part (or multi unit) symbols. (I 
do not really see a clear indication for these features in your document.)


Is there a definition for having only some units exchangeable?
Is there a way to define a unit as "must be placed" or "optional"?
Is there a way to mark a unit as "power unit" (I think you mentioned 
sometime back that this might be required to properly make simulation 
for multi unit symbols possible while still allowing the power unit to 
be separate. A power unit would also be a "must be placed unit" but i 
feel separating these two might add more flexibility.)


On 01/01/19 20:59, Wayne Stambaugh wrote:

I have updated and published the symbol file format[1] for comment.
Hopefully there isn't too much to change.  The only thing to really
finalize is the internal units.  The initial concept was unitless but
the more I think about it and discuss with other developers, it makes
more sense to use units for the following reasons:

1. It's easier to visualize in your head how the symbols on a given page
size will layout.

2. Converting from other file formats (Eagle, Altium, etc) will be
easier since most if not all of them have a defined unit.

I'm thinking 10u (or possibly 100u) will make a good internal units
value.  Once we nail down the units, I will update the file format
document accordingly.

Please keep in mind that this is the symbol library file format document
so things like constraints belong in the schematic file format.  I will
be posting the schematic file format as soon as I finish updating it.

Cheers,

Wayne

[1]:
https://docs.google.com/document/d/1lyL_8FWZRouMkwqLiIt84rd2Htg4v1vz8_2MzRKHRkc/edit


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




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

Re: [Kicad-developers] What is the difference between the use of 3d model search path entries and normal path variables (environment variables)?

[Rene Pöschl]

Sadly these do not really answer my questions.

On 15/01/19 17:25, Mário Luzeiro wrote:

Hi Rene,

Not sure if it is documented.
Cirilo was the main person on the development of the 3D searching paths.
Searching the mailing list there may be some hints to this questions, but it 
may not be totally true or updated at this moment:

https://lists.launchpad.net/kicad-developers/msg24138.html
https://lists.launchpad.net/kicad-developers/msg14225.html
https://lists.launchpad.net/kicad-developers/msg24232.html

Regards,
Mario Luzeiro


From: Kicad-developers  
on behalf of Rene Pöschl 
Sent: 11 January 2019 17:25
To: KiCad Developers
Subject: [Kicad-developers] What is the difference between the use of 3d model 
search path entries and normal path variables (environment variables)?

Hi,

I noticed that the configure path tool in the footprint editor has a new
part added to it. This part seems to manage 3d model search directories.
Such a search directory consists of the path, an alias, and a description.
As there is a way to change the order of search path entries i would
guess that there is also prioritization at play.

Could someone detail how this would be used? Would it clash with the use
of normal path variables (after all our official footprints all use the
KISYS3DMOD path variable)? Which of the two is preferred assuming these
two are meant to serve the same usecase?

___
Mailing list: https://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] 5.0.2 stable release.

[Rene Pöschl]

How does a package get karma? Can the community perhaps help out in some 
way?


On 04/12/18 19:57, Steven A. Falco wrote:

My build of kicad-5.0.2-1.fc29 has completed in the Fedora buildsystem, and 
I've submitted it for testing.  Thus, the build should show up in the 
updates-testing repo as soon as a release engineer pushes it along - usually 
that takes a day or two.

After that, if it receives enough (positive) karma, it will move into the 
updates repo.

I'll note that last time (for 5.0.1), there was insufficient karma, so the 
5.0.1 build had to sit for an extra week in the updates-testing repo before it 
became eligible for promotion to the updates repo.

Steve


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

Re: [Kicad-developers] 5.0.2 stable release.

[Rene Pöschl]

The libs are now tagged.

On 03/12/18 13:49, Wayne Stambaugh wrote:

I saw that the translation and doc repos were tagged for 5.0.2.  Where
do we stand on the library repos?

On 11/26/2018 6:49 PM, Evan Shultz wrote:

I should have also mentioned that the outstanding items milestoned for
5.0.2 are actual fixes which we would like to include. We've been
careful not to pushing breaking changes flippantly so tagging the head
of each library should be safe and an improvement. Breaking changes
haven't been intentionally made since 5.0.0 unless it was to fix an
issue that might ruin a design (wrong pinout, footprint pins swapped, etc.).

On Mon, Nov 26, 2018 at 3:08 PM Evan Shultz mailto:evan.shu...@gmail.com>> wrote:

 Yay!

 We (librarians) have a few outstanding items in the library we want
 to close before 5.0.2, but it should only be a couple of days and
 well within the one week timeline you requested. Thanks mostly to
 Antonio, we're now using the milestone feature of GH so you can see
 what's left at https://github.com/KiCad/kicad-symbols/milestone/6
 and https://github.com/KiCad/kicad-footprints/milestone/1 (for
 symbols and footprints, at least).

 On Mon, Nov 26, 2018 at 3:05 PM Wayne Stambaugh
 mailto:stambau...@gmail.com>> wrote:

 I just tagged and pushed 5.0.2 so we need to decide what we want
 to do
 about tagging the library and translation repos.  Rene, any
 thoughts on
 the library repos.  I know there have been a lot of changes
 since 5.0.1
 but as long as the existing symbols have changed too
 significantly, I'm
 fine with tagging the current head of each library.

 On 11/26/2018 5:55 PM, Nick Østergaard wrote:
 > Are we expecting to tag 5.0.1 as 5.0.2 for the libraries or are we
 > getting a minor library update as well?
 > On Mon, 26 Nov 2018 at 20:32, Wayne Stambaugh
 mailto:stambau...@gmail.com>> wrote:
 >>
 >> I just noticed a few last minute changes were made to the 5.0
 branch.
 >> Is there anything else pending or am I good to go with
 tagging 5.0.2?
 >>
 >> Cheers,
 >>
 >> Wayne
 >>
 >> On 11/25/2018 2:01 PM, Wayne Stambaugh wrote:
 >>> I plan on tagging 5.0.2 tomorrow unless is a show stopper
 bug that I am
 >>> not aware of.  My goal is to give the library, doc, and
 translations a
 >>> week to get tagged for 5.0.2 and another week for the
 installers to get
 >>> built so I can make the release announcement on 12/9.
 Please let me
 >>> know if this doesn't fit into your schedule so we can make
 other plans.
 >>>
 >>> Once 5.0.2 is released, I would like to string freeze the
 development
 >>> branch to start getting ready of 5.1 release candidates by
 the beginning
 >>> of the year.  If you have any UI string changes that you are
 planning to
 >>> make, now would be a good time.
 >>>
 >>> Thank you again everyone for your hard work.  KiCad continues to
 >>> steadily improve due to your efforts.
 >>>
 >>> 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] 5.0.2 stable release.

[Rene Pöschl]

I am a bit out of the loop sadly as i had quite a busy month behind me 
(new job plus some old responsibilities)


I created an issue over at the symbol repo. [1] Both to ask the other 
librarians and for a place to report design breaking changes. (A few 
symbols have been changed since 5.0.1 it seems.)
If there are no objections then i will tag tomorrow morning before i go 
to work (~06:45 CET)
A word of warning: My internet seems to be a bit unstable. If i do not 
tag tomorrow then it might have been broken completely.


[1]: https://github.com/KiCad/kicad-symbols/issues/1213

On 03/12/18 13:49, Wayne Stambaugh wrote:

I saw that the translation and doc repos were tagged for 5.0.2.  Where
do we stand on the library repos?

On 11/26/2018 6:49 PM, Evan Shultz wrote:

I should have also mentioned that the outstanding items milestoned for
5.0.2 are actual fixes which we would like to include. We've been
careful not to pushing breaking changes flippantly so tagging the head
of each library should be safe and an improvement. Breaking changes
haven't been intentionally made since 5.0.0 unless it was to fix an
issue that might ruin a design (wrong pinout, footprint pins swapped, etc.).

On Mon, Nov 26, 2018 at 3:08 PM Evan Shultz mailto:evan.shu...@gmail.com>> wrote:

 Yay!

 We (librarians) have a few outstanding items in the library we want
 to close before 5.0.2, but it should only be a couple of days and
 well within the one week timeline you requested. Thanks mostly to
 Antonio, we're now using the milestone feature of GH so you can see
 what's left at https://github.com/KiCad/kicad-symbols/milestone/6
 and https://github.com/KiCad/kicad-footprints/milestone/1 (for
 symbols and footprints, at least).

 On Mon, Nov 26, 2018 at 3:05 PM Wayne Stambaugh
 mailto:stambau...@gmail.com>> wrote:

 I just tagged and pushed 5.0.2 so we need to decide what we want
 to do
 about tagging the library and translation repos.  Rene, any
 thoughts on
 the library repos.  I know there have been a lot of changes
 since 5.0.1
 but as long as the existing symbols have changed too
 significantly, I'm
 fine with tagging the current head of each library.

 On 11/26/2018 5:55 PM, Nick Østergaard wrote:
 > Are we expecting to tag 5.0.1 as 5.0.2 for the libraries or are we
 > getting a minor library update as well?
 > On Mon, 26 Nov 2018 at 20:32, Wayne Stambaugh
 mailto:stambau...@gmail.com>> wrote:
 >>
 >> I just noticed a few last minute changes were made to the 5.0
 branch.
 >> Is there anything else pending or am I good to go with
 tagging 5.0.2?
 >>
 >> Cheers,
 >>
 >> Wayne
 >>
 >> On 11/25/2018 2:01 PM, Wayne Stambaugh wrote:
 >>> I plan on tagging 5.0.2 tomorrow unless is a show stopper
 bug that I am
 >>> not aware of.  My goal is to give the library, doc, and
 translations a
 >>> week to get tagged for 5.0.2 and another week for the
 installers to get
 >>> built so I can make the release announcement on 12/9.
 Please let me
 >>> know if this doesn't fit into your schedule so we can make
 other plans.
 >>>
 >>> Once 5.0.2 is released, I would like to string freeze the
 development
 >>> branch to start getting ready of 5.1 release candidates by
 the beginning
 >>> of the year.  If you have any UI string changes that you are
 planning to
 >>> make, now would be a good time.
 >>>
 >>> Thank you again everyone for your hard work.  KiCad continues to
 >>> steadily improve due to your efforts.
 >>>
 >>> 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: 

[Kicad-developers] Has the handling of the datasheet field changed again?

[Rene Pöschl]

Is it possible that the datasheet field has been moved to the lib file 
in the current nightly builds? That would break our testscripts and 
create unnecessary noise on github. I thought the solution (for v5) has 
been that the field of the lib file is filled with the one from the dcm 
file if it is left empty. However it seems one can not fill the dcm file 
version for a symbol that is not an alias.



___
Mailing list: https://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] Has the handling of the datasheet field changed again?

[Rene Pöschl]

On 21/11/2018 18:38, Jeff Young wrote:

Version 5.0.x (and version 4.0.x) gave us the option to store the datasheets 
for both
aliases and main symbols in the dcm file.

Right; that hasn’t changed.  What’s changed (or should have changed) is that 
the above is the *only* option.

So is it not OK for that to be the only option, or is it just not working that 
way?

(Sorry for not testing it myself, but I’m knee-deep in the 
paste-symbol-twice-revert crash bug.)


We just need a way to set the datasheet stuff in the dcm file for non 
aliases. Right now there is only one input field that stores it in the 
lib file.


One option that comes to mind is that the current layout of one entry 
field is kept. But that there is some setting that controls if it is 
stored in the dcm or lib file. (If we simply say that the current entry 
field saves to the dcm file someone who currently uses only the lib file 
field will be unhappy.)



___
Mailing list: https://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] Has the handling of the datasheet field changed again?

[Rene Pöschl]

On 21/11/2018 17:41, Jeff Young wrote:

@Wayne,


This is a limitation of the current symbol file format but the root datasheet 
field
should be empty and the datasheet url should be stored in the document file
along with the description and keywords.  This way it's consistent with all of 
the
alias information and doesn't violate the KLC.

Are you sure that’s not backwards?  That’s the way I changed the internals to 
work.  (Perhaps we still have code to map it to the other way on output, but 
then that wouldn’t have changed.)



Version 5.0.x (and version 4.0.x) gave us the option to store the 
datasheets for both aliases and main symbols in the  dcm file. This 
means it is consistent no matter what type a symbol is. This makes our 
testscripts easy as we only need to check the dcm file for documentation 
information. For this reason we do not allow any symbol to have the 
datasheet field of the lib file filled in the official lib. (this is 
also where the noise would come from. With the current way of the 
implementation the datasheet field of symbols would move from one file 
to the other.)



The way it was in v5.0.1 is as follows: If the datasheet field of the 
lib file is empty it gets overwritten with the one from the dcm file 
when placing a symbol into the schematic.



For you this means that even if the documentation fields stay in the 
general tab they should still all be saved in the dcm file.



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