Suggestion learning kiCAD source code

I’m a software engineer and have over ten years of C++ linux/ARM experience. Currently I’m interested in EDA/CAD/HPC development, so I download kiCAD project and build them.
Currently I found some links:

  1. | Developer Documentation | KiCad
  2. kicad mail-list
  3. kicad forum
  4. some kicad usage docs.

I think the listed docs not enouth to start learning the kiCAD’s source code.
Please give me some suggestions, learning path.

For me it’s easiest to learn when I’m doing something practical. I have a goal in mind, a feature I want to build and I just go in and do it. I figure out what I need as I go.

Why are you trying to understand kicad’s source? Do you want to build some feature? If you have something specific in mind it’s best to discuss it with devs first (unless you don’t plan to merge it upstream).

If you don’t have anything specific then take a look at issue tracker, there are a bunch of starter bugs that can get you started on simple stuff. Then look at upvoted feature requests, maybe you will like something.

KiCad is a complex project, there is a lot of code. There is GUI, renderers (yes, multiple), file formats, importers and exporters, configs, tool framework, 2d and 3d geometry logic, ERC/DRC checkers and rules, scripting layer, simple package manager, and more. It’s not a textbook to learn from cover to cover, learn what you need to achieve what you want.

1 Like

Maybe this is true for most of the people, at least for me.

I have also wanted a hands on guide to the source code. A short introduction to the files (beyond the obvious) and classes. The source code is poorly documented. What would be especially helpful would be to take a workflow, say, open the application, start a new project, add a symbol to schematic, update the pcb, route, add graphics, zones etc., check, create gerbers… and go through the classess involved. Not too detailed, of course, but to get an overview.

So, like, 90% of all classes, lol.

You will never have this kind of documentation, it’s not a thing in large projects. Good code is self documenting and KiCad is mostly good code. There is still a bunch of legacy code that will… hm… surprise you sometimes but it’s getting better all the time.

It’s important to understand a few general things, for example how wxWidgets works, how rendering works, how the data is modeled and then you pull on these strings to untie the knot.

Let’s say netlist exporters. At present, I’m figuring out how the netlist exporters work. What we want to do is as following:

  1. Get the current schematic’s S-Express or XML content (It’s better in memory, not in a file);
  2. Do some translation;
  3. Write into a new netlist format.

After seeing the code in kicad/eeschema/netlist_exporters, I cannot grasp the whole idea how to get my above goal done. Lots things need to be undstanded.

Ho nice if there is a tutorial to guide how to write netlist exporters.

Tutorials and guides are written for things that lots of people need to learn on a regular basis. They are written because it saves time to not repeat yourself.

I doubt someone will consider it useful to spend time writing a guide for something so niche as netlist exporters. Especially since like all docs it would have to be maintained as code changes. Devs are expected to be able to trace function calls and class usages to figure such things out.

In your case what I would do is look at what is happening when eeschema generates xml netlist. You can track it down from corresponding button click handler. Then look how other netlist exporters are “registered” in the system so eeschema knows about them. Try and copy things at first, adapt as needed. Use logging to figure out what happens or doesn’t happen and when it happens.

1 Like

So, we have to dive into the code. Thanks for your suggestion.

Yeah, it’s sort of the nature of the beast. Since KiCad is almost entirely constructed from volunteer labour, it’s hard to get someone excited about spending their Sunday documenting the code or writing tutorials…

Thanks for all of your discussion. Maybe it will get more time to get start.

We maintain a list of “starter” bugs / feature requests that might present a reasonable goal for your first contribution:

It is often best to start with something small so you can get the KiCad-specific contribution process figured out with a feature that is already approved by the development team.

3 Likes

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