Hi experts,
I have created a symbol library in “Symbol editor” in Eeschema. This symbol lib contains about 5 symbols also created directly in “Symbol Editor”. The symbols can be used in Eeschma as usual. The created library is visible in “Manage symbol libraries” and Windows explorer as well.
However, in Windows Explorer, if try to see which symbols does the library contains, it is not possible.
That is, I can’t expand it to see the lib contents. This is probably because under “Windows Explorer” the library is listed as a file with an ending “.lib”. which of course can’t be expanded.
I must have made a mistake in the process of symbol library creation but I can’t figure out where I made it. Was it a mistake to create a library under “Symbol Editor” and then add more symbols to it? If yes, how can I correct this now, please?
I wish to create a folder under “Windows Explorer” having a name (say) “My Symbols”, and in that folder keep all existing self-created, without having to recreate them. And, of course, that folder would be visible under “Symbol Editor” and “Manage Symbol Libraries”.
Each symbol library is one file. Naturally it can’t be expanded in a file manager. The footprints are different: each footprint is one file, and a “library” is a folder.
@eelik
Thanks for your quick response. As I hinted in my question mail, it is known to me that the “.lib” can not be expanded in Explorer. My problem was since I had created a lib in the “Symbol Editor” and then added a few symbols to it I could not see the list of my own symbols outside a Kicad project.
Now, I have tried the following:
Created a new folder in Windows Explorer for my symbols
Exported one by one all of my existing symbols from “Symbol Editor” into this newly created folder
Deleted the existing symbols in “Symbol Editor” through "Manage Symbol Libraries.
Re-added all individual symbols one by one from the newly created folder to the list of symbols in KiCad using the “Add Library” command in the “Edit Symbols”.
As a result, now I have a folder in Explorer where I can see which symbols of my own creations are there. Actually, it is just like adding the Digikey Symbol library to Kicad.
If you see any potential problems in this approach, kindly let me know, please. Your advice is most welcome.
Note, in KiCad up to the v5.x.x releases the symbol libraries are actually in two files, the .lib which contains the geometries for each symbol and the .dcm which contains the documentation details for each symbols. As all the symbols within the libraries are all part of the same file(s) currently the only way to see what symbols are in each library outside of KiCad is with a text editor. But, coming up in v6 the schematic libraries will be organized similar to the footprints where a library will be a filesystem directory and the individual symbols will be individual files. This will fit what you want. Hopefully v6 will be released early next year and should be able to upgrade your current v5.x.x format symbol library(ies) to the new v6 so I don’t know how much effort you want to put into your method of spreading the symbols out to individual files.
EDIT: I was wrong. My incorrect statement is now struck-through.
I don’t think so. From what i see on the official lib the new file format is still many assets per file. See all these kicad_sym files over on the repo https://gitlab.com/kicad/libraries/kicad-symbols
The reason here might be the inheritance feature that kind of requires the source asset to be in the same file (if i remember the info given by wayne correctly)
Also consider the problems we already have with loading times on the footprint side. These would be much worse on the symbol side as there are a lot more symbols than footprints.
Oh, bummer. I guess my misunderstanding was more wishful thinking. I did notice that it appears that the .lib and the .dcm assets have been combined into a single .kicad_sym file, so that is something…
To be honest i am not even sure it was ever a good idea to go towards one file per asset. There are very few usecases that can not be done in a one file per lib format.
The only one that comes to mind is version control and that is solvable even in a one file per lib format. At least for most users (the official lib is an exception here as we have a lot more people contributing to it than even a large corporation would).
All one really needs to do is have clear and consistent line ordering where small changes to an asset only affect the lines responsible for whatever was changed (not like now where moving a few pads can change basically the complete footprint file).
And maybe a “combine libraries” tool that does simple merges (where for example two people added different assets but the lib is otherwise unchanged).
When the .pretty footprint libraries first came out I did like the ability to easily move a footprint once finished building and tweaking from my sandbox library to its eventual home just by moving a file. But that was before the library name became part of the footprint reference in the netlist… And I admit that I abused the living daylights out of selective ordering of the libraries in the symbol footprint tables to get my assets to be found before the distributed libraries so I could automagically “overwrite” with my own modifications. Again, v5 foiled my nefarious plans.
