search

KiCad / kicad-footprints

Official KiCad Footprint Libraries for Kicad version 5
https://kicad.github.io/footprints
Other
620 stars 712 forks source link

Too many footprints in several libs #544

Open evanshultz opened 6 years ago

evanshultz commented 6 years ago

@poeschlr @jkriege2 @Ratfink @Misca1234 KLC says we should only have 250 footprints or symbols in a lib. Some of our footprint libs are exceeding this number.

I do notice with all current libs that invoking all footprint libraries (in Pcbnew or footprint editor) does take quite a while. I'm not sure if splitting them up would really help this, but when loading only a single library's footprints it should help. (Loading all libs in Eeschema or CvPcb takes an annoyingly long time as well, but this is about footprints.)

The exact qty of footprints changes nearly daily, but as of right now here are some libs that have 250 (or nearly that many) footprints:

And here are two things which I noticed when looking at this as well:

poeschlr commented 6 years ago

@SchrodingersGat was there any reasoning behind choosing the number 250 as the lib size limit?

I am not so sure 250 should be a hard cap but more of a "start to worry if the lib might grow" value.

We truly run into trouble with libs > 1000 footprints as github can not handle that many files well. (Or 500 if you expect every footprint to come with its own 3d model.)

Splitting connector libs at least should not create problems on the symbol lib side of things. But it will again require updating the 3d model side. (And this must be done at the same time. No exceptions!)

Touching the TO_SOT libs will create a lot of work on the symbol side with very limited gains. (All of that shortly before a major release. So i don't like that idea.) The same is true for the package dip lib. (I don't expect too much growth for this lib. So i would not start to worry till we get > 300 footprints in it.)

I would not split the pin header and pin socket libs. We already have a lot of these libs. (I also don't really expect a lot of growth in these.)

Molex an JST are hard to decide. If we split them by family we easily get 30 new libs. (With some of them holding only 5 or so footprints.) Splitting by smd vs tht does not really make sense as it will split families. (And might not really help in the end.)

The samtec lib basically holds only one series. All connectors are horizontal and have the same pitch and the same number of rows. Maybe split out that family and keep all other (and future contributions) in the connector_samtec lib. (would avoid problems with future growth as i think all footprints for that particular family are present in the current lib.)

Cap_THT: well i don't really expect much growth here. So we don't need to go too fine grained. (But splitting by general body shape might work. So cylindrical, disc, rectangular with rectangular resulting as the largest lib of them.)

Phoenix is a hard nut to crack. If all possible MC and MSTB footprints are added both libs will have way more than 1000 footprints. Splitting by connection direction might help a bit. By pin pitch might also help.

Molex, JST and phoenix would require updating the generator scripts.

Tldr: What we really should do: split the one large samtec connector series into it's own lib. (that lib will hold > 250 files but i think it is ok)

What we definitely should not touch are the pin header and socket libs, to_sot and dip.

Everything else depends on finding a nice solution that works and enough manpower to get it done quickly.

SchrodingersGat commented 6 years ago

The 250 requirement was purely arbitrary - mostly chosen because currently in the footprint selector window there is no filtering option so scrolling through > 250 items to find the one you want is tedious.

Increasing this number should be fine, though.

Ratfink commented 6 years ago

Depending on the outcome of #474, we may end up getting quite a few new THT capacitors. (Please add any suggestions you may have there, I'm still waiting for good naming to proceed with making those footprints.)

poeschlr commented 6 years ago

For JST and molex maybe an option might be to split them by pin pitch ranges. So something like

If we can find a good naming convention for that it might just work.

Edit: why not use the pin pitch directly? Well i tried that, got 30 libs with some of them having 5 parts in them. (Especially for molex as they have quite a lot of imperial grid sizes in addition to their metric grids.)

poeschlr commented 6 years ago

@evanshultz you merged two of the pull requests connected to this. Would you take a look at the other two? (I would like this done before rc2)

evanshultz commented 5 years ago

The DFN/QFN repo now has 300 files in it, nearly doubling in the last six months! The awesome generator you wrote, Rene, makes it easy to add footprints and is probably part of the explanation. Also being specific about having the correct EP size made the file count explode. And using the generator for a footprint with an EP gives a via and non-via version, doubling the file count for each submission.

So... I realize changing this would result in a ton of work but would we expect another doubling in the next six months? If so, we're well above 500 and in a year would be at 1000. I doubt the growth will continue at this rate but it's something to keep an eye on.

If we do decide to split this at some point it will need to be planned and implemented carefully and by a team for doing the modifications and review.

Misca1234 commented 5 years ago

If "KLC says we should only have 250 footprints or symbols in a lib" is not really a hard cap but more of "because currently in the footprint selector window there is no filtering option so scrolling through > 250 items to find the one you want is tedious"

That is, it is a usability questions, which means that the worries raised originally for this thread is really not a reality. The long loading times is also a usability issue.

For me, both these issues "belongs to the coders" and not the librarians, splitting libraries should be done if it benefit the maintenance of the libraries or if there is a source code bug that can not be solved in another way.

Beside abov: we could execute a collector script which create a "quick search database" before each release which the kicad platform can use for fast finding, I guess today kicad scans all libraries and all files every time to create a database in RAM.

poeschlr commented 5 years ago

I would say the soft cap of 250 parts can remain. (As soon as a lib hits that or is in danger of hitting it we should think about splitting it in the next major release. This would be version 6 in this case. My guess would be that we will split the libs between DFN and QFN parts.)

The real hard cap for me is somewhere above 500 files. This is the part where githubs interfaces simply break down.

myfreescalewebpage commented 5 years ago

Hi,

Just reading your comments and would react about one thing:

The real hard cap for me is somewhere above 500 files. This is the part where githubs interfaces simply break down.

That's only on the github interface itself and the limit is 1000 files, a warning is displayed when this occurs (example below from linux kernel repo where many many files are handled by github - we should not expect issues with Kicad even with the current grow of libraries):

capture

When working on your computer you have OS limitations to take care, which are not everywhere the same (number of files/directories depending of partition type). Anyway you can manage several hundred of files without to worry and we have probably time to think about that.

So, is the github interface really an issue ? I don't think many people search for symbols/footprints looking on github !

PS : new symbols editor interface with quick search textbox on the left is really nice, any plan to have it on the footprint editor also instead of loading library and then listing symbols ?

Cheers, Joel

poeschlr commented 5 years ago

The github interface is an issue for us maintainers. And also for users who want to browse the libs on the github site. We should really aim for limits that guarantee that all github features still work. (Why would we be on github otherwise?)

The 500 cap is because every footprint needs to files in the 3d repo (wrl and step). We learned that the hard way with the old phoenix contact organization.

The footprint editor will look the same as the symbol editor does as soon as v5.1 is released.

myfreescalewebpage commented 5 years ago

The 500 cap is because every footprint needs to files in the 3d repo (wrl and step).

Yes right, understood.

We learned that the hard way with the old phoenix contact organization.

OK.

The footprint editor will look the same as the symbol editor does as soon as v5.1 is released.

Great !!