Idea to allow nested footprint modules


#1

Hy,

The problem I would like to mitigate largly arrised because of big repositories like for example: https://github.com/KiCad/Connectors_Phoenix.pretty

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

Support of Directories in the .pretty format

PRO

  • structure inside kicad and external ones matches
  • easier to refactor
    CONS
  • not backward compatible

What are your thoughts about this idea?


#2

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.


#3

I like the second option better … Also for the symbols that would be a great addition, when we get the new format!

Best,
JAN


#4

I like the second option better … Also for the symbols that would be a great addition, when we get the new format!

Best,

JAN

Thomas Pointhuber <info@kicad.info> hat am 29. Juni 2017 um 12:24 geschrieben:

pointhi

June 29

Hy,

The problem I would like to mitigate largly arrised because of big repositories like for example: https://github.com/KiCad/Connectors_Phoenix.pretty

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

Support of Directories in the .pretty format

PRO

  • structure inside kicad and external ones matches

  • easier to refactor

CONS

  • not backward compatible

What are your thoughts about this idea?

--

Visit Topic or reply to this email to respond.

To unsubscribe from these emails, click here.


#5

Non back compatibility would make a mess for users IMO…

A group key would be a nice improvement …
My 2 cents


#6

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.


#7

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.)


#8

There are several issues with sub-folders.

e.g What happens when the sub-folders contain duplicate file names? Does the FPID identify the top folder, or the path to the kicad_mod file?

Apart from being a major change to KiCad that won’t happen until 2019, probably

This is hinting at the XY problem https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem. Is the problem actually having a lot of files in one folder, or is it really a problem with finding things efficiently?

I suggest that Kicad devs should really be asked for input, otherwise this will likely be added to the wishlist and never get done.


#9

Actually I didn’t realise those fields are already there,

  (descr "2x7-segments, 14 mm, Kingbright DA56 displays")
  (tags "7-segments display")

All the elements are already there, add the required tags to the files, and it just needs a filter box/dialog like the Component Chooser.


#10

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


#11

Ah, I forgot them as well. So far didn’t populate them as I didn’t see them used anywhere, esp with the way I use my libs :wink:


#12

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.)


#13

I agree with that statement. KiCad 5 will bring rounded pads, which means some libraries won’t be compatible with the old version anyway.


#14

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


#15

As long as v5 can read the old files and libraries I’m fine :smiley:
thx
Maurice