Even if you had a different file format for a single symbol, that doesn’t solve the tedium of people who obtain them one at a time and need to put them into a library. That they try to treat each symbol as a library by itself will have to solved by patient explanation.
There are small changes that can be made, one I pointed out above is to allow importing multiple symbols in one go. Another more complex would be to detect multiple symbol libraries in the import list and provide a dialogue to choose which members to import.
The software can distinguish one and multiple symbol libraries, all it has to do is count the symbols. It probably has to scan the file for correctness anyway.
PS: It’s also worth remarking that this isn’t the original hell suffered by the OP who was confused that symbol libraries are files, while footprint libraries are directories. Then joojala raised the issue of the poor software support for managing libraries. Somebody chimed in with the mistaken notion that each symbol file could only hold one symbol, a notion generated by Internet repos that return one symbol at a time.
Still not ready to request a feature. But what if a single object library loading would automatically trigger a what library do you want to put this in dialog?
So a lazy selection for the destination library? That’s certainly possible in addition to selecting it ahead of time. There are places where lazy selection could be allowed, one is the creation of writable libraries when creating symbols or footprints, instead of having to do it ahead of time.
The Ki Library organization was a surprise, and counterintuitive. There are industry standards and conventions that should better be adopted.
The nomenclature could be made to be more standards conforming too, perhaps contained in a “language setting”.
Transitioning from another CAD program with different paradigms is tedious.
Like in Ki, a Symbol is not just a “symbol”, but a text file that is a library with many symbols a.k.a a directory, which is linked to specific footprints “libraries”, which are individual files.
Why not have a Device for each part, under which there is a single Symbol, which can have multiple Footprints with individual pin connections?
A Device, say a single OP-amp, which can have 13,387 different part numbers, can use a single Symbol, have different part numbers being subsets of a single Device with a single, or multiple, Footprints?
A link to a datasheet is handy, but more editable text information could be included with a Device, like brief functional descriptions, price, hyperlinks to vendors, for BOM generation et cetera. Ki has made paradigm shifts before, and its able creators could undoubtedly figure out something better.
Adding some standard fields like MPN, HPN etc. has been discussed many times. I can say that most of the suggested fields will not be added to the official libraries. The reason is simple: you can add what you want and there’s no one size which would fit all. If you don’t like KiCad’s libraries, just create your own (by copying the existing ones) and add the information you want. If you don’t like the symbol/footprint file system, you can use database libraries.
In the end I don’t think the library formats are actually a problem. The management UI may be.
@eelik Just look at any other PCB EDA program, there are many.
Calling a collection of individual entries a “file” and “Symbol Library” a single entry should be self explanatory.
Have you ever seen a library with one book?
No I won’t. I’m not interested enough and I don’t see need for that. If you are inclined to and consider this important enough, you can do the research and write some kind of document.
That’s irrelevant. People can organize their libraries as they want to, with one or more symbols or footprints in one library. As I said, it’s more about how the program lets the users manage those libraries.
3rd party exported libraries are one specific problem, users can see the library file but doesn’t necessarily know how to handle it correctly. That’s not a problem in the file itself (although, as I have said, maybe it could be changed) but in the human/computer interaction. Changing the library file format could be an easy way to solve the problem but it wouldn’t of course solve all problems – and any library system of any EDA has problems.
I didn’t say that. Just that “a library of one book” is irrelevant for our discussion about KiCad libraries. And if I continue: the analogy of “library” breaks anyway because usually there are no several book libraries side by side, each having different items. If you insist on analogy, the name “library” should be changed to “shelf” or something like that – in every EDA.
The official KiCad libraries don’t probably have one item libraries. Every user who collects their own libraries may or may not have one item libraries, according to their own will, and KiCad doesn’t prevent or commend that. It’s neutral and let’s the user decide, as it should.
As far as I can see the only concrete problem in this thread has been that some people don’t know how to manage their libraries (and their could be some bugs, of course). In that problem KiCad should definitely help. A high level application shouldn’t require knowing low level details about the implementation to use the software, although I very much like the fact that KiCad allows touching low level and I like hacking.
Well, there are a few basic solutions:
1: Go with one of your “standard conformant” (ain’t that a joke) packages and pay the dollars needed.
2: Participate actively in the library development group.
3: Use the software as it is, and be very happy that so many enthusiastic people have created a highly professional EDA tool. FOR FREE!!!
Last, you seem to be a new user of KiCAD. Get acquainted with it first without thinking of the EDA tool you worked with last.
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.
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.
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.
