Improving library editor checks


I’ve been playing a little bit with KiCad source code for the first time. I’ve decided to implement some KLC checking into the symbol library editor based on what was already available on pinedit.cpp just to get in touch with the source code.

My changes are available at

There is a pipeline that builds an AppImage whenever I push new changes to that repo. The latest AppImage available at the moment can be downloaded from

Here is a screenshot of the improved existing dialog:

I think this feature could be useful for many users and it would probably simplify librarian work when reviewing contributions in Github. For this reason I would like to get some pointers on how should this feature should be implemented so that developers would be willing to merge possible changes in case I finally decide to implement this. Also from what I know there will be a ERC/DRC system rewrite that may lead to reusable codebase for this project.

Can anybody provide any pointers for me?

Thank you!


In general the best place to ask about anything regarding the kicad codebase is the mailing list.


I believe credible error checking is always a welcome addition to any situation.

But please, make provision for the user to over-ride the error check and save the symbol regardless of how messed up it seems to be.



I would not make the check on save but by separate user action that simply makes a report if the user asks for it. Like ERC and DRC i would keep the user in charge if they do anything about the reported errors. (I would assume this was the plan by @avb as well as he kind of mentioned ERC here which also works that way.)


I think I will give it a go although I have practically never used a mailing list and I am afraid of not using it correctly.

Oh yes! Don’t worry about that! Worst case scenario this will be the button with the annoying KLC check tool but I believe it should never be a limitation to your freedom or workflow, independently on how much your standards differ from KLC.

Yes. That was my plan.



Pretty easy, Antón: you send an email and everyone in the list receives it. You also receive any email sent by anyone :smile:.




Although you can check the mailing list log, I thought that it may be desirable to summarize the thread here so that users not following the mailing list can comment.

After my original message the following concerns arised:

  • KLC has it’s own schedule so coding it into KiCad will lead to checks being obsolete between releases.
  • Although my code modularized the checking process, I was asked to be more generic, eg. provide pin on grid check instead od KLC rule S4.1.
  • KLC is not for every KiCad user so we should not code KLC checks into KiCad as many will not want that.

From that feedback we came up with the idea to provide a interface that would allow us to ship rule checking packages written in python that could be enabled, disabled and updated as needed. A list of desired features could be:

  • Rule checking written in Python
  • Rule packages that could be redistributed
  • Rule packages that could be enabled or disabled
  • KiCad package path to search for rule packages
  • Possibility of adding rule set from a dedicated folder that could be saved into a project file
  • Possibility of live/automatic checking based on settings


If the kicad-library-utils/Travis python script could be run directly inside kicad, it could avoid some maintaining of the checking scripts :slight_smile:


Currently they use a purpose build parser of the file formats. This would not make any sense if it is run within kicad. I suspect one would either need to write a translater between kicad and the scripts or rewrite the scripts to directly use kicad internal data.


In order to avoid having to maintain two sets of scripts I would vote to handle things through KiCad. For Travis/Gitlab testing of elements it is not difficult to create a docker image with the latest KiCad version installed and my original idea was to be able to run the checks in command line only also.

I am not to sure on how this is going to be implemented though.


A mostly unrelated remark:

Edit: Oops, another brainfart of mine?

Most of the footprints in KiCad’s offical libraries are generated by scripts, but there are also the “Footprint Wizard” scripts, which are separate, and seem to be getting a bit outdated. For example the QFN Wizard I bumped into recently does not support the rounded corners which were recently introduced in KiCad.

This seems to be a simple way for someone with a bit of Python knowledge to improve. Ether by updating those scripts, or writing an interface, so both can use the same Footprint Generator scripts.


wizards and our scripts have a very different usecase. We want to mass produce loads of different footprints with a single command and having a permanent storage of the device parameters. (As we want to be able to easily update footprints to new standards.)

A wizard produces a single footprint with an easy to understand graphical interface probably for one time use. (You would use a script with permanent storage of parameters otherwise.) It does not require permanent storage of parameters as the footprint is its storage. (In fact there is no way to store generator parameters in the footprint itself.)

Would it be possible? Yea probably. But don’t expect us librarians to invest time into this thing that is of no use to us. (To be honest something similar applies to the KLC scripts. Why push them into kicad if it does not really help with continued integration testing that kind of requires direct commandline input/output instead of graphical communication which a DRC requires.)


This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.