It is quite a long story, and it explains the origin of your confusion, but for the most part it is not very relevant for the path names. For example, the troubles with 3D models are not related to the symbols.
What KiCad does:
Every symbol in the schematic has a [Lib Nickname] / [Symbol Name] combination.
The [Library Nickname] can be either a global or project specific library.(Project specific library overrides (and hides) nicknames in the global library table).
The Nickname can be different from the library name.
Nickname is expanded to a full library path.
Full library path is built upon environment variables.
There can be automatic translation between KICAD6_3DMODEL_DIR and KICAD7_3DMODEL_DIR. I do not know whether KiCad also does something similar with KICAD6_SYMBOL_DIR (and/or for footprints).
Did I miss something in that summary?
There is enough translation going on that having the ability to quickly and unambiguously identify the origin of a schematic symbol can help with troubleshooting. Especially that a nickname in the projectâs library table can overrule a global library can be confusing. (Consider open source projects here, where someone modifying it often knows very little about the origins of a project).
I guess this is worth a feature request.
I agree that the 3D models issue is not related to the symbols library per se. However it IS related to the footprint libraries and the path variables and nick names by which they are found.
The title of my original post included both symbol and footprint as the target of my question, given that the library path variable mechanisms for both types of object are quite parallel, with equivalent tables, nicknames etc.
Regarding your description of the [Lib Nickname] / [Symbol Name] mechanism â I would add a couple of additional points:
What Kicad calls âEnvironment Variablesâ are actually not âEnvironment Variablesâ in the normal sense of Operating System or session environment variables. Instead they are variables internal to Kicad, and stored in a file somewhere. However, those internal variables CAN be overridden by actual environment variables of the same name, if set.
So thatâs a potential extra source of confusion â an OS environment environment variable thatâs set when you didnât expect it, or the reverse, you set an OS environment variable, but for some reason Kicad doesnât see it â perhaps a spelling mistake.
I should also point out that the user is free to add their own variables to the Configure Paths âEnvironment Variablesâ list. I find this quite a useful feature. But itâs a further opportunity for a variable to not to work as expected.
By the way, I have no beef with Kicadâs path scheme per se â itâs pretty straightforward with about the right amount of indirection for my purposes. My only wish is for a completely unambiguous way to see the actual path that Kicad calculated for a particular symbol on a schematic or footprint on a PCB. That would be helpful.
On this one point, I wouldnât expect there to be behind the scenes translation for those variables, because I donât think any other files (previously created in K6) refer to symbols or footprints or their libraries by file path.
The situation with 3D models is unique in that the footprint library file refers to a 3D model file using the 3D modelâs directory, which is simplified by using an environment variable in that path. So footprint files brought over from K6 contain the variable " KICAD6_3DMODEL_DIR", and those would all need to be changed in both the Kicad-supplied and userâs local libraries.
In contrast, when a symbol library refers to a footprint, it uses the nickname to do so, avoiding use of the file path, and thus no need for an environment variable.
The irregularity here is that there is no 3D model manager and table of nicknames for the 3d model libraries, that would parallel the symbol manager and table, and the footprint manager and table. Hence the 3d footprints donât have nicknames, and so footprint filesâ references to them have to resort to file path, simplified by at least using the KICAD6_3DMODEL_DIR environment variable.
and assign to then the folders where I want to put these local libraries. Then I can use these variables where needed (such as in Symbol Managerâs table and Footprint Managerâs table).
I donât recall where or if Iâve used the other variables, but a minor point is that itâs convenient to have them recorded in the Configure Paths, alongside the KICAD7_xxx variables.
I will have to keep an eye on the fate of these user-defined variables in case I need to devise a different strategy for K8.