IMPORTANT: Symbol Library Table Merged into Development Branch


Thanks Rene, I had not fully discovered the table editor, I thought it was just for displaying an overview, but discovered now one can update the fields. However I found the edit to be a bit shaky. Sometime it would take a double click, other time not. And if I edit and apply changes to one field the next symbol I click on will also get that value, so may be some more work is needed there (using unsigned Dec. 8 Windows nightly).

I do think see what Nicholas is after though, One has created a schematic, without much metadate or with incorrect ones in it and now you want to use a pre-existing “molecular” part to get that metadata for BOM/ordering info updated instead of retyping it in again.

For my molecular parts, I have symbol names like R_1206_10K_RC1206FR-0710K and with all needed footprint and ordering info defined. On insertion I change the value to 10K. The part will still reference R_1206_10K_RC1206FR-0710K in my custom library, it is just the displayed value that is changed. If I look at its properties all the original info for that part is displayed and ready for use in Pcbnew or creating a BOM.


I see now that a later nightly carries the possibilty to read in the fields from the lib when you open the properties dialog in eeschema

this is such a great step forward in the right direction.

now you should also be given the possibility within same properties dialogue to do this on all components of same value, not only the one you opened the prop dialogue on

unfortunately when you read in text fields that was not placed before in the schematic they end up far away from the component.

but still a great step forward


another problem found is that the visibility (show) properties as stored in the library is not honored.

fields gets in, but show flags are not updated.


That might be worth raising a bug report


I did

20 chars 20 chars 20 chars


After some more checking to confirm on latest nightly I filed a bug report on the Component Table editing :


Post 25th November on Windows has not even been tried by many users. A big risk since V5 release is creeping up


Some of use like to live dangerously :relaxed: . Actually if there is a time one should go for the nightly that is in the pre-release period after the feature freeze (which is already in effect) to help developers pinpoint as many bugs as possible before the final V5 release.

Some precautions are vise though: frequent backups of everything of course, keeping up to date on what is going on on the bug tracker and the KiCad code list with repect to recent changes (I like this view ), and perhaps above all (that probably applies to any version in use now): Not to rely on referencing the official kicad libraries directly even when stored locally, or at least not at time of conversion to the new sym-lib-table format, as they are being reorganized and one could risk soon obsolete library names to get hard coded into the project files at conversion. And of course the risk might not be worth taking for time critical projects in the final stages. One should not go into this expecting that everything works perfectly.

I usually do this kind of testing with a separate installation in a VM, but right now I have reorganized my custom library and successfully converted all my projects to the new sym-lib-table format for my main installation after the initial testing period in a VM (only relying on two libraries: my own custom library and the official power library). I am really impressed with how responsive the developers are to the bug reports. Also one should not overlook the fact that the nighties have many bugs fixed that have existed for a long time, not only in the later versions.


Exactly, but the unsigned Nightlies are not exactly easy to find from the KiCad website


There are some clues in the link below. :wink: I only noticed the second time I read it:

(Not so easy to find, but I feel uncertain if the bandwidth of that site can take a more public approach).


There has to be a way of manually copying an unsigned build onto the official server.
There have been several significant changes such as the threaded zone filling, which really need mass testing


This explains why the windows installer is signed in the first place (Explanation by MS).

The reason it would be important for me:
Ensuring integrity. (Has somebody outside the kicad developers tempered with the installer? The package could even be tempered with in transit. Downloading unsigned stuff is a big security risk.) This of course only works if the code signing procedure is itself secure.


So a V5 release cannot happen until code signing is sorted out


I am not sure if this will impact the v5 release.
The latest update from wayne was that he plans to split the v5 branch around Christmas, with the v5 release planned for the first week of februar. (But he mentioned that this might be a bit optimistic.)

You could ask over at the mailing list if you want clarification. (I am not involved in any of this.)


If history is a guide, the release process for v4 took from about design freeze in March to final release in December 2015, and I don’t see any reason why v5 would be any different. That would suggest final v5 will not be until August 2018.


I don’t see the process taking that long as Nightlies have been fairly clean for a long time. Once the library reshuffle is finished a 5.0.0 is possible.
There is also a lot of pressure to avoid 4.0.8, 4.0.9 etc


Well the library team can not support any further v4 release. (We already moved to the new repos.)
So if there really is a 4.0.8 release it will get the 4.0.7 libs.


A signed Nightly 12/12/17 put up last night :clap:
Let’s get testing


And search tree in Symbol Library Editor, sometimes works, sometimes not…


Look at the mailing list. There seem to be platform specific problems.
I think reporting a bug about your specific behavior might be a good idea.