Library Management HeLL

Single symbol libraries are going to slow opening KiCad a lot - the way files get opened in Windows the first time in a session.

Sounds like a good feature request to make

Be my guest @joojala

Posting a reply because this is one of the things I’m trying to wrap my head around.
I’ve tried using KiCad in the past a few times to see if it could work for me, never really got into it.

However, now I would really like learn to use it and the thing that makes my head spin most is libraries, components, symbols, directory structures, filetypes, paths and whatnot…

So yeah, not a concrete question but I’m also in the “Library Management HeLL” :slight_smile:

Have you gone through the getting started guide? If so, are there parts of it that could be more clear?

As well as the “Beginners Guide” tutorial, there is a FAQ for creating and manipulating Personal Libraries here.

Your comments on the FAQ would be appreciated also.

Over the years I have seen that library management is the most difficult part of KiCad for many users. Rene Pöschl, who was the head of the library team for a long time, insisted that it’s not difficult, but I begged to differ back then and still do.

Unfortunately it’s not very simple to magically suddenly make it easy. Changing the system radically would probably be counterproductive for development of KiCad and for many users, probably for the majority of the old users. It’s difficult to pinpoint all the smaller issues which, if taken together, would make it considerably easier. But small steps seem to be the way to go.

Well, yes and no, and why not? Actually KiCad does have a format for passing around a single symbol – kind of. The problem (with the 3rd party symbol generators) is that there’s no explicit file format for it.

KiCad already understands a single symbol without a library. That’s easy to demonstrate by copying one symbol and pasting it to a text editor, then copying from the text editor and pasting to a library in the symbol editor/manager. Why not add a new file format, say, “.kicad_sym_nolibrary” which has only symbol(s), not the library information? It wouldn’t be used in the KiCad library lists as it is, but it could be exported and imported. The 3rd party services could export that file and the user could import it to an existing library.

EDIT: I just noticed that symbols without the containing library can be imported from kicad_sym file to an existing library. What makes it confusing and non-intuitive is that the same file format is used primarily as a library, not for an export/import container, and does a double duty. Therefore it has to be learned and remembered first.

2 Likes

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.

1 Like

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.

1 Like

Please give details.

Again, please give pointers to the standards.

Certainly, so why don’t those other CAD programs change their paradigms?

That’s not a simple question and there are many viewpoints. See for example New component or part format with embedded or linked symbol, footprint and 3d files (#6941) · Issues · KiCad / KiCad Source Code / kicad · GitLab and Feature Request - Having a True Component Library Management (#6313) · Issues · KiCad / KiCad Source Code / kicad · GitLab and Custom pin mapping between symbol and footprint (lp:#1803145) (#2282) · Issues · KiCad / KiCad Source Code / kicad · GitLab.

You can add as many custom fields as you want to.

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?

1 Like

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.

Why would you think common words and paradigms are irrelevant?

1 Like

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.

1 Like

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.

Apologies if this was already linked above and I missed it, but one existing feature request that those participating here might want to “thumbs up” is: Wishlist: one file per symbol in eeschema libraries. (lp:#1842206) (#2490) · Issues · KiCad / KiCad Source Code / kicad · GitLab to allow symbols to be in individual files like footprints.

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.