Those repositories contain multiple hundreds of footprints, and I think it would be a bad idea to further split them. Instead of, I would likely see the feature to group them together by series for example. This thread is supposed to create a discussion about the general idea, as well as how different solution would work out. Which means it would be especially improtant to be discussed by Library Maintainers (@SchrodingersGat, @Rene_Poschl, @jkriege2,…) as well as developers (@nickoe, …)
My proposal would allow us to nest footprints inside groups visualized by the kicad viewer. Those are generated based on informations inside the .pretty repo.
Currently, I have two ideas how we could achive that:
Add a additional group keyword in the footprint module, which is then used by the viewer
PRO
should be fully backward compatible
CONS
repos still contains multiple hundreds of footprints in one directory
structure is not represented in the normal file explorer
I noticed this too. Of course, it’s fantastic that all these footprints are now there, let’s make it clear we are not complaining about too many footprints! It’s just a question of how to manage them.
For components, they have a description and keywords field. That works really with the Component Chooser (and I think dev builds have a filter box in cvpcb). I think a similar filter box would work well for footprints, even without extra fields, because there are keywords in the file name. So typing “MST ang” would cut to the list to a manageable number.
I’m not in favor of creating sub-folders, it’s a very poor way of creating an indexed database. It would be really nice if footprints had description and keywords, even nicer if it was possible to add any meta data in a forward/backward compatible way (it’s possible, but requires more effort than simply rejecting unknown data).
Adding fields is not an option until probably v6 now - many years hence. (If I was in charge, I would make the data file format forward compatible, but I’m not and it is not KiCad policy.)
But I think the situation can be improved by simple text search on filenames, which doesn’t require significant changes to code, file format or repo layout.
Those repositories contain multiple hundreds of footprints, and I think it would be a bad idea to further split them. Instead of, I would likely see the feature to group them together by series for example. This thread is supposed to create a discussion about the general idea, as well as how different solution would work out. Which means it would be especially improtant to be discussed by Library Maintainers (@SchrodingersGat, @Rene_Poschl, @jkriege2,....) as well as developers (@nickoe, ...)
My proposal would allow us to nest footprints inside groups visualized by the kicad viewer. Those are generated based on informations inside the .pretty repo.
Currently, I have two ideas how we could achive that:
Add a additional group keyword in the footprint module, which is then used by the viewer
PRO
should be fully backward compatible
CONS
repos still contains multiple hundreds of footprints in one directory
structure is not represented in the normal file explorer
IMHO I always prefer it if the meta information is stored right with the data - if possible at all - and not dependent by how or where the data is actually stored.
The schematic symbols do that pretty well, with their F0…Fx fields.
The Footprints should have something like that too.
Everything else is always more a matter of the user interface and how much thought & work has been put into that.
The parts picker in the nightlies is a good example of that.
I think for a major release backwards compatibility is not really much of a concern. (It might be a bit late for v5 though.)
Both ideas would be better then the current mess.
I think the keyword based stuff could already work with the current functionality. We just need rules for what should be in the keyword field.
I would go away from the one repo per lib model. So it would anyways be a good idea to support sub directories in the footprint repo(s)
Why then stop at one layer.
In conclusion option 2 might be the better option in the long run. Option 1 might be something that can be implemented till release 5. (Just add an option to filter by the already existing keyword field and make rules how this keyword field should be filled.)
if you review a project after some time, you will be forced to change all the file in the project…
I’m fine in improving features, but at the same time I like a stability for roots
I’m not even sure the proposed change would make this impossible.
The footprints would still be added to the project file. And i even think the old repos would still work. (It might be necessary to download them by hand thought.)
That would be forward compatibility though. As long as v5 can read the old files backwards compatibility is given.
The new schematic lib might break direct backward compatibility. But i assume there will be a conversion script similar to what happend between kicad 3.x and 4.x
