The first stab at true library symbol inheritance was recently merged into the development branch of KiCad and will be available in next nightly builds. Saving to the legacy symbol library file format is no longer possible because the legacy format cannot support symbol field inheritance. You must first save legacy libraries to the new symbol library file format before you can use the field inheritance feature.
This change only implements derived symbol field inheritance from a single parent symbol. I suspect that this use case actually provides most user’s inheritance requirements. The inheritance is pretty basic when adding a new symbol to a schematic the following inheritance rules apply:
Symbols that do not derive from other symbols (root symbols) are used as is.
If a field is defined in the parent symbol but not in the derived symbol then the field from the parent symbol is used.
If a field is defined in the derived symbol but not in the parent symbol then the field from the derived symbol is used.
If a filed is defined in the derived symbol and in the parent symbol, the field from the derived symbol is used.
This change required rethinking how the symbol library editor displays derived symbols. I opted for what I thought would be the least confusing option so only the fields defined in derived symbols are shown on the canvas and in the symbol properties dialog. Fields inherited from the parent symbol are not shown when editing a derived symbol. I thought it would be confusing to show fields that cannot be edited but I am open suggestion regarding how to best handle this.
Below is a simple root symbol with an optional field.
Below is derived symbol that inherits from the root symbol above. Notice the footprint and datasheet fields from the root symbol are not shown. Only the fields provided by the inherited symbol are shown.
Below are the properties of the inherited symbol. Notice that the “reference” field and optional field “opt-field-parent-1” have a different values than the root symbol. This will replace the field in the parent when added to a schematic. This includes all field properties not just the values.
@Andy_P This only applies to fields. Complex inheritance like you described isn’t implement yet. When that will happen is still up in the air. I have a bunch of schematic feature requests that I’m working on at the moment. I also want to get feel for how inherited fields play out before I tackle the much far more involve implementation of complex inheritance.
This looks very promising, thanks for all the work. I’ll give this all a go when available in the nightlies and provide more feedback if required. In the meantime, just a comment.
I think it’s very useful, when browsing the library, to see which symbol is the parent. I use that frequently when reviewing library submissions.
With the current system, I used to double click on the symbol name and see where it jumps (because it opens the main symbol). It isn’t great because you need a lot of clicking and it jumps around all the time. Is there a way on the new system without opening the properties? Anything planned.
A feature to group symbols by parent in the tree would be extremely useful in my opinion.
@diegoherranz Changing the library tree sorting might be useful but a better solution might be to add an extra tree node so that all derived symbols are listed in a separate node under the parent symbol. Making changes to the library tree code is not trivial so that would take a significant commitment of time to implement. In the short term, would a context menu entry to open the parent symbols suffice?
Having extra tree nodes for the root symbols would be very useful at some point in the future, and I think it would be a very clear way of showing it. The context menu entry would definitely help in the meantime. Thanks.
A few random things after using it a bit today. Let me know if any deserves a bug, and I can create it.
I think that the fourth image is not showing the properties?
Inspect > Electrical Rules checker shows “No pins” for children.
If you open an old library, modify something and try to save it, nothing complains but no file is saved?
Related to the previous one, how is this expected to work? Will the old aliases be saved as derived symbols automatically?
Just to make sure I understand it correctly. There won’t be a file per symbol because of the inheritance, but there will be one .kicad_sym file per family (parent + children) all within a .sweet folder for each library. Is that correct?
Thanks!
Application: KiCad
Version: 5.99.0-unknown-3bd4c0c~101~ubuntu20.04.1, release build
Libraries:
wxWidgets 3.0.4
libcurl/7.68.0 OpenSSL/1.1.1f zlib/1.2.11 brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.2.0) libssh/0.9.3/openssl/zlib nghttp2/1.40.0 librtmp/2.3
Platform: Linux 5.4.0-33-generic x86_64, 64 bit, Little endian, wxGTK
Build Info:
Build date: Jun 3 2020 15:17:40
wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.24
Boost: 1.71.0
OCE: 6.9.1
Curl: 7.68.0
Compiler: GCC 9.3.0 with C++ ABI 1013
I decided that I would leave this as a decision for the user. You can create symbol libraries with one symbol per file or multiple symbols per file. Each file will have to be a separate entry symbol library table. There is no support for opening multiple symbol library files in a folder (ala footprint libraries) at the moment. Parent symbols of derived symbols must be contained in the same library file. There is no external parent symbol linking. This would require remembering to copy multiple symbol library files to ensure that derived symbols are not orphaned which would not be very portable.
I played with the symbol inheritance a bit. My idea was to use a generic resistor symbol, add all the necessary fields like Footprint, Supplier, Tolerance, Power etc. all with a placeholder value or leave it empty.
I then wanted to create a resistor symbol for a 0603 1% resistor derived from the generic resistor symbol and fill in the fields like Footprint, Tolerance, Power.
From the 0603 1% resistor symbol then I wanted to derive a symbol like a 100 Ohm, 1%, 0603 resistor and fill in the relevant fields for that symbol. However I seems I can’t derive a symbol from an already derived symbol. Is this correct? Will this be implemented? I think, showing all the fields in the inherited symbol would be better, not only the derived ones, maybe have a button in the Library Symbol Properties dialog to switch these fields on and off, or show all the fields in another tab.
@rrascher Only single level of inheritance is supported at the moment. Hopefully I will get around to implementing multiple levels of inheritance before V6 is release. This will be have to done incrementally because of the complexity of the changes to the symbol library editor.
Create an abstract symbol type that can be inherited from. Since you are mainly concerned with single level inheritance, that would prevent inheritance creep over time.
In addition to replacement inheritance, you might consider making constraints available for inheriting components.
Together these two ideas will help maintain a disciplined approach to inheritance that allows for flexibility and consistency. Nothing should prevent users from creating a new abstract type, but people using this new type will need to check for inheritance consistency, where as if they are using a derived part from a well accepted abstraction, they can be assured that it will continue to offer good results.
You can plan for a similar inheritance style for pads and placement. EMI considerations, or impedance rules for connecting are examples of ideas that could make an inheritable object placement model rock.
The classic way this is done in software development is to refer back to the parent, but not to keep long lists of children in parents. The situation begs for a relational database. There is an easily added flat flile database that can be incorporated easily. The big change would be in the code if it doesnt have a data abstraction layer yet. My suggestion of creating abstract objects to inherit from documented in another thread can help keep the hierarchy straighter.
Thanks, @stambaughw, for your reply. A few comments.
Checked on a current nightly and it is disabled for the derived symbols. That’s better than the error. Thanks.
Regarding Save As:
I see that it is now fixed. I’m able now to save a complete library in the new format. Thanks.
Regarding one file per symbol/family:
This basically forces you to have all the symbols in one file, otherwise maintaining the symbol library becomes very difficult.
Is that planned? I think it would be great! And I think it would be appreciated for the official library management (fewer merge conflicts). Also, everything would behave more similarly between symbols and footprints, which always makes it easier to understand to the user.
I think this restriction is reasonable. Even if a library was structured as one file per symbol, keeping the derived symbols in the same file as the root symbol sounds OK to me.
I’m still getting my head around the UI in terms of Fields for the derived symbol. I think it would be nice to show which ones are being overwritten or added and which ones are used from the root symbol. I find it a bit confusing at the moment. Not sure how to show that on the UI, though. If I come up with an idea I’ll let you know.
