I gave it a thumbs down.
1 Like
So did I; but then I’m just a silly old fart who spent some time reading and experimenting so I understood how the libraries work when I first started using Kicad.
As far as I know, there once was a plan to change to one file per symbol system and the only reason it was given up was that it would be problematic for inheritance/derivation. Otherwise it would be better to have one symbol in one file, for obvious reasons: compatibility with footprint system, easier to understand and handle for users (as we have seen).
I added a remark to the gitlab issue linked to by Scandey, and I guess it’s appropriate here too:
This is not an important issue for me, but I do find it a bit weird that footprint libraries have one footprint per file in a directory, while symbols are packed together in a single file. I would prefer them to have similar formats.
I guess it would not be very hard to write a script to split a symbol library into individual files, and to combine them again. Maybe this can be added to KiCad-cli.
Both approaches have their advantages and disadvantages. I don’t know how much of an performance issue it is if symbol libraries were split into one file per symbol. KiCad also already does have separate symbol files, but not as part of a library.
In a more general sense I prefer to have better library management tools in KiCad. A split between the “pinned” libraries and the other libraries so each can be scrolled separately will help (Maybe worth a feature request…). Another improvement is drag and drop from one KiCad instance to another.
With library management inside KiCad you can also do a (zoomable) thumbnail preview of all symbols (or footprints) in a library. This could also be written as a plugin for your operating system. Thumbnail generators for images for example are common.
Ideas are cheap, and the most precious resource for KiCad are the developers and the time they have available.
Having one symbol per file has the drawback of lots more file I/O too. Compatibility with the footprint system is only for people who care about implementation details. When the user interface is properly implemented, nobody should care that a symbol library is an archive in a file. There are a lot of precedents where a single file is a library, e.g. object libraries for programming language linkers.
1 Like
I guess both packed and unpacked symbol format will eventually supported. When you are making and delivering symbols unpacked format comes handy, but when you are using symbols packed format is lot quick to load into memory. Just be patient when the devs are busy sorting things out.
Here are two issues tracking this:
1 Like
I’m a bit concerned that this topic is turning into a epic thread for all sorts of issues with libraries. Already there are distinct issues mentioned. Perhaps this topic should be closed off and new posts should start their own topic.
2 Likes